"Representational State Transfer (REST) is a style of architecture for distributed hypermedia systems such as the World Wide Web." (Roy Fielding 2000 )

• REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used.
• REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.
• In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture. RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete?) operations.
• REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.). Later, we will see how much more simple REST is.
• 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 Perl, Java, or C#.

BY DR. M. ELKSTEIN

Characteristics :

• client-server
• stateless (no stored context in server)
• cache (label each response as cacheable /non-cacheable)
• uniform interface (generic interface HTTP, GET, POST, PUT, DELETE to access resources)
• Named resources - using URL
• Interconnected resource representation - the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another.
• Layered components - intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, etc.

Principles:

• Identify all of the conceptual entities you wish to expose as Services.
• Create a URL to EACH resource (NOUNS, not VERBS!) : ​http://localhost:8080/ontocat/rest/gene/name_of_gene NOT ​http://localhost:8080/ontocat/rest/get?name=... *
• Categorize your resources according to whether users can just receive a representation of the resource, or whether users can modify (add to) the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE.
• All resources accessible via HTTP GET should be side-effect free. That is, the resource should just return a representation of the resource. Invoking the resource should not result in modifying the resource.
• No man/woman is an island. Likewise, no representation should be an island. In other words, put hyperlinks within resource representations to enable users to drill down for more information, and/or to obtain related information.
• Design to reveal data gradually. Don't reveal everything in a single response document. Provide hyperlinks to obtain more details
• Specify the format of response data using a schema (DTD, W3C Schema, RelaxNG, or Schematron - ). For those services that require a POST or PUT to it, also provide a schema to specify the format of the response.8. Describe how your services are to be invoked using either a WSDL document, or simply an HTML document.
• Describe how your services are to be invoked using either a WSDL document, or simply an HTML document.

REST Server Responses :

• often an XML file
• JSON, CSV

AJAX & REST :

• In many ways AJAX applications follow the REST design principle. In AJAX, requests are sent to the server using XMLHttpRequest objects. The response is used by the JavaScript code to dynamically change the current page.
• Each XMLHttpRequest can be viewed as a REST service request, sent using GET. And the response is often in JSON.

(​http://www.xfront.com/REST-Web-Services.html

​http://rest.elkstein.org/2008/02/what-is-rest.html)