One of the senior developers from Qubiz has accepted the invitation to talk about RESTful service. We have started to use RESTful services for a while and our customers are very happy with the results.
What is REST?
Representational State Transfer (REST) is a derivation of World Wide Web’s architectural style. REST is a style, not a standard. There is neither a REST RFC, nor a REST protocol specification. But REST defines how to use the existing Web standards in a better way by trying ”to minimize latency and network communication, while at the same time maximizing the independence and scalability of component implementations” (Roy Fielding, in his dissertation about REST).More specific, REST is an architectural style for building client-server applications by implementing services based on HTTP protocol. Domain-specific data (resources) are transmitted over HTTP without an additional messaging layer such as SOAP or session tracking via HTTP cookies.
Why would we use REST?
The architectural style described by REST is simpler, more open, more scalable and more consistent with other Internet protocols (REST is basically HTTP) than the alternative protocols referred as WS-*.
REST simplifies web services by using HTTP protocol’s full specs in order to make it easier to express what a service does.
REST shifts the execution model from a remote procedure call to changing the state of a domain object. Working with a RESTful web service looks like working with a database record (get an object from the DB, change it, and save the changes) than calling a remote procedure.
Some of the best-known cloud services use REST, including APIs from Amazon, SalesForce and Google.
What distinguishes REST from SOAP?
SOAP defines a transport neutral model focused on operations (or actions). SOAP-based services usually have only one URI and many different actions. REST defines a transport specific (HTTP) model focused on resources (domain-specific data). RESTful services have different URIs for each resource.
How is the REST learning experience?
Being familiar with HTTP protocol, REST has a smooth learning curve. The most important aspect is to understand how to implement REST correctly. There are implementations on the market asserting they are REST, but they are not real RESTful services.
Any final advice on REST?
If you need to expose web services and begin now the implementation, do them RESTful. This will make your clients happier.
Think about implementing security in a very early stage of the project.
Qubiz has recently implemented a complex set of RESTful services exposed by one of our customer's software system. The services are consumed by an existing native mobile application which manages loyalty points when buying goods from a selected brand.
Other web links on this subject: