A REST (REpresentational State Transfer) service is based on some basic concepts of the web such as the HTTP protocol and the HTTP verbs (GET, POST…). When using a REST service, we need to send a request to a particular URL and a response will be returned. This response is unique, based on the URL: never should a specific URL return a different schema of the response. The best example of a REST implementation is the web itself: when we send a request to a particular URL, we’ll get back a response. Such a response is generally known as a resource in the REST terminology. The response is plain text, XML or JSON. The schema for this response can be seen as a contract: the service promises that the response will always be of the specified format. This way, we can write parsing code for the schema.
Over the last couple of years, REST has gained a lot of traction, mainly because of its simplicity. People are moving their services to REST in favor of SOAP-based services such as WCF. For many scenarios, REST is more than enough: simply sending a request and receiving a clear-text response makes thing simple. And isn’t that what we want?!
Many big sites including Facebook, Twitter, Flickr and many more offer a REST API. Application developers can therefore easily connect with available services by sending a request to a URL dictated by the site (including some parameters such as a search term). The response is XML or JSON and the response format is specified by the API as well.
