Representational state transfer (REST) is the software architectural style of the World Wide Web.It relies on a stateless, client-server, cacheable communications protocol — and in virtually all cases, the HTTP protocol is used.

REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.).

Despite being simple, REST is fully-featured; there’s basically nothing you can do in Web Services that can’t be done with a RESTful architecture. REST is not a “standard”. There will never be a W3C recommendataion for REST, for example. And while there are REST programming frameworks, working with REST is so simple that you can often “roll your own” with standard library features in languages like PHP, Perl, Java, or C#.
REST was defined by Roy Thomas Fielding in his 2000 PhD dissertation “Architectural Styles and the Design of Network-based Software Architectures”.
REST is the underlying architectural principle of the web. The amazing thing about the web is the fact that clients (browsers) and servers can interact in complex ways without the client knowing anything beforehand about the server and the resources it hosts. The key constraint is that the server and client must both agree on the media used, which in the case of the web is HTML.

An API that adheres to the principles of REST does not require the client to know anything about the structure of the API. Rather, the server needs to provide whatever information the client needs to interact with the service. An HTML form is an example of this: The server specifies the location of the resource, and the required fields. The browser doesn’t know in advance where to submit the information, and it doesn’t know in advance what information to submit. Both forms of information are entirely supplied by the server.

So, how does this apply to HTTP, and how can it be implemented in practice? HTTP is oriented around verbs and resources. The two verbs in mainstream usage are GET and POST, which I think everyone will recognize. However, the HTTP standard defines several others such as PUT and DELETE. These verbs are then applied to resources, according to the instructions provided by the server.resources being manipulated using a common set of verbs: HTTP methods are the commonly seen case – the venerable Create, Retrieve, Update, Delete becomes POST, GET, PUT, and DELETE

For example, Let’s imagine that we have a user database that is managed by a web service. Our service uses a custom hypermedia based on JSON, for which we assign the mimetypeapplication/json+userdb (There might also be an application/xml+userdb andapplication/whatever+userdb – many media types may be supported). The client and the server has both been programmed to understand this format, but they don’t know anything about each other.

The REST API lets you interact with Parse from anything that can send an HTTP request. There are many things you can do with the REST API. For example:

  • A mobile website can access Parse data from JavaScript.
  • A webserver can show data from Parse on a website.
  • You can upload large amounts of data that will later be consumed in a mobile app.
  • You can download recent data to run your own custom analytics.
  • Applications written in any programming language can interact with data on Parse.
  • You can export all of your data if you no longer want to use Parse.