REST stands for Representational State Transfer and is a design architecture for networked applications. The key aspects of REST are that it is resource-based, with resources identified by URLs. Clients access and perform operations on resources using standard HTTP methods like GET, POST, PUT, and DELETE. Requests should be stateless and responses cacheable to allow for scalability. There are six main constraints for RESTful architecture including a uniform interface, statelessness, client-server style, cacheability, layered system, and code on demand.

1. REST
 What is REST...?
Thisarticle presumesbasicunderstandingof how internetworks,whatwebappsare,whata webservice isanda
some basicunderstandingof networking.
Representational State Transfer(REST) isa designarchitecture fornetworkedapplicationsorsystems.Inthe
REST designarchitecture aclientprogressesthroughanapplicationbyselectinglinks,alsoknownasstate
transitions.Eachlinkselectedbythe clientreturnsarepresentation of the selectedresource.Also,witheach
resource representationthe clientapplicationtransfersstate,andresultsinausable webpage beingtransferred
and rendered.
In the REST designarchitecture,aresource iscreatedforeveryservice thatanapplicationprovides,witheach
resource identifiedbyaURL. A clientcan reference the resource usingthe URL.The returnedrepresentationof
the resource isfurtherlinkedtomore information,allowingthe clienttodrill downasfaras necessarytoget
more detailedinformation.The clientcanaccessandperformoperationsonavailableresourceswithstandard
HTTP methods,suchas GET, POST, PUT, and DELETE.
 REST stands forRepresentational State Transfer
 Main aspects are
1. It isa "resource-based"webarchitecture
 We thinkof “resources”(ornouns) v/s“actions”/“methods” asinSOAPRPC. We thinkin
termsof verbs.
 Resource = URI, that is,UniformResource Identifier.Itisa stringof charactersusedto
identifythe resource.Suchidentificationenablesinteractionwithrepresentationsof the
resource overa network,typicallyworldwideweb,usingspecificprotocols.
2. Representations
 It signifies howresourcesgetmanipulated withhelpof API
 Representationsgettransferredbetweenclient-server
 Example:Resource=person(sayTodd), Service=GET, Representation=infoinJSON orXML
format.
 Typicallyformatssuchas JSON,XML, CSV,HTML. etc. are usedtoconveyrepresentations.
 There are six importantconstraints forRESTful architecture.Theseare
1. Uniforminterface
 Client-serverinterface
 URI
 Actionsallowed withURI = GET,PUT, POST, DELETE (these are CRUD functionalities)
 POST=create or append;PUT=create or replace
 HTTP response foranyaction isrequiredtobe the http statusand response body
2. Stateless
 Servershouldcontainnoclientstate;everyclientrequestisindependent.
 Serveris idempotent(detail innextsection)
3. Client-Server
4. Cacheable
 Serverresponsesare cacheable
5. Layered system
 Client-serverconnectionis layered (scalability)

2. 6. Code on demand
 Servercan “optionally”sendJavaScriptor Javaappletcode snippettoexecute onclient
 A web-service isasoftware thatmakesitself available overHTTPand usesstandardXML or JSON based
communicationprotocol andgetrequest/response acrossclient-server.Platformindependent,language
independent,loose coupling,supportsRPC…
 Idempotence
For a RESTful service call to be idempotent,clientscan make that same call repeatedlywhile producingthe same
result.Making multiple identical requestshasthe same effectas making a single request. While idempotent
operationsproduce same resultonserver(noside effects),the response itselfmaynot be same.
The PUT and DELETE methodsare definedtobe idempotent.
(There is a caveaton DELETE. The problemwith DELETE, which if successfulwould normally return a 200 (OK) or204
(No Content),willoften return a 404 (NotFound) on subsequentcalls,unlesstheservice is configured to "mark"
resourcesfordeletion without actually deleting them. However,when theservice actually deletes the resource,the
nextcall will notfind the resourceto delete it and return a 404. However,the stateon the serveris thesame after
each DELETE call, butthe responseis different.)
GET, HEAD,OPTIONSand TRACEmethodsare definedassafe,meaningtheyare onlyintendedforretrievingdata.
Thismakesthemidempotentaswell since multiple,identical requestswill behave the same.
HTTP Method Idempotent Safe
OPTIONS yes yes
GET yes yes
HEAD yes yes
PUT yes no
POST no no
DELETE yes no
PATCH no no
 References
1. http://www.tutorialspoint.com/webservices/what_are_web_services.htm
- Specificallythe RESTsection
2. https://access.redhat.com/site/documentation/en-US/OpenShift/2.0/html-
single/REST_API_Guide/index.html#sect-API_Guide-General_API-Link_Navigation
3. https://access.redhat.com/site/documentation/en-US/OpenShift/2.0/html-
single/REST_API_Guide/index.html#chap-API_Guide-API_Entry_Point