Archive for the ‘rest’ tag
Why REST?
The original promise of web services was simplicity. Simplicity is the S in SOAP or Simple Open Access Protocol, although nobody calls it that anymore. A bewildering number of WS-* standards has been introduced over the past near decade, causing Tim Bray, Canadian entrepreneur and co-editor of the XML specification, to declare WS-* a failure:
In fact, a recent poll by Information Week found that 58% of IT professionals believed that SOA introduced more complexity [more like 58% of companies dissatisfied with SOA (32% of all companies), but still significant] and resulted in cost overruns. Some industry pundits, such as Tim Bray, echo this sentiment declaring WS-* an embarrassing failure.
The new game in town is REST or REpresentational State Transfer. It proposes a simpler way of defining and accessing web services, based on a combination of HTTP and a payload of ASCII, XML, or JSON. Most importantly, it decouples clients from details of service behavior, and focuses on the data model instead. It offers a clean break from the remote-procedure style of application integration.
REST is thus far simpler than SOAP. REST services are easier to develop and deploy, and accessing a REST service only requires reading from an URL. Companies like Google ditched their SOAP interfaces in favor of a RESTful interface. While supporting SOAP, Amazon has seen a 20% to 80% split between users of its SOAP and REST service interfaces. A REST service provides access to resources identified by URLs. The operations offered by HTTP (PUT, GET, POST, DELETE) provide a uniform way for accessing those resources, and correspond to the familiar CRUD (Create Read Update Delete) operations.