REST-style architectures consist of clients and servers. Clients initiate requests to servers; servers process requests and return appropriate responses. Requests and responses are built around the transfer of representations of resources. A resource can be essentially any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document that captures the current or intended state of a resource.


The client begins sending requests when it is ready to make the transition to a new state. While one or more requests are outstanding, the client is considered to be in transition. The representation of each application state contains links that may be used the next time the client chooses to initiate a new state transition.[8]

 REST facilitates the transaction between web servers by allowing loose coupling between different services. REST is less strongly typed than its counterpart, SOAP
REST does not require XML parsing and doesn’t require a message header to and from a service provider. This ultimately uses less bandwidth. REST is also different from SOAP in that error handling is different between the two. SOAP can have user defined error messages while REST requires the use of HTTP error handling. REST also only support synchronous (in contrast to asynchronous) messaging, because of its reliance on HTTP and HTTPS infrastructure. This increases the number of threads in use by a REST web service.
  1. GET
  2. POST
  3. PUT

Like Web Services, REST offers no built-in security features, encryption, session management, QoS guarantees, etc. But also as with Web Services, these can be added by building on top of HTTP:

  • For security, username/password tokens are often used.
  • For encryption, REST can be used on top of HTTPS (secure sockets).