Roger L. Costello I will first provide a brief introduction to REST and then describe how to build Web services in the REST style. What is REST? REST is a term...See more »
Roger L. Costello I will first provide a brief introduction to REST and then describe how to build Web services in the REST style. What is REST? REST is a term coined by Roy Fielding in his Ph.D. dissertation [1] to describe an architecture style of networked systems. REST is an acronym standing for Representational State Transfer. Why is it called Representational State Transfer? The Web is comprised of resources. A resource is any item of interest. For example, the Boeing Aircraft Corp may define a 747 resource. Clients may access that resource with this URL: http://www.boeing.com/aircraft/747 A representation of the resource is returned (e.g., Boeing747.html). The representation places the client application in a state. The result of the client traversing a hyperlink in Boeing747.html is another resource is accessed. The new representation places the client application into yet another state. Thus, the client application changes (transfers) state with each resource representation --> Representational State Transfer! Here is Roy Fielding's explanation of the meaning of Representational State Transfer: "Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use." Motivation for REST The motivation for REST was to capture the characteristics of the Web which made the Web successful. Subsequently these characteristics are being used to guide the evolution of the Web. REST - An Architectural Style, Not a Standard REST is not a standard. You will not see the W3C putting out a REST specification. You will not see IBM or Microsoft or Sun selling a REST developer's toolkit. Why? Because REST is just an architectural style. You can't bottle up that style. You can only understand it, and design your Web services in that style. (Analogous to the client-server architectural style. There is no client-server standard.) While REST is not a standard, it does use standards: * HTTP * URL * XML/HTML/GIF/JPEG/etc (Resource Representations) * text/xml, text/html, image/gif, image/jpeg, etc (MIME Types) The Classic REST System The Web is a REST system! Many of those Web services that you have been using these many years - book-ordering services, search services, online dictionary services, etc - are REST-based Web services. Alas, you have been using REST, building REST services and you didn't even know it. REST is concerned with the "big picture" of the Web. It does not deal with implementation details (e.g., using Java servlets or CGI to implement a Web service). So let's look at an example of creating a Web service from the REST "big picture" perspective. Parts Depot Web Services Parts Depot, Inc (fictitious company) has deployed some web services to enable its customers to: * get a list of parts * get detailed information about a particular part * submit a Purchase Order (PO) Let's consider how each of these services are implemented in a RESTful fashion. Get Parts List The web service makes available a URL to a parts list resource. For example, a client would use this URL to get the parts list: http://www.parts-depot.com/parts Note that "how" the web service generates the parts list is completely transparent to the client. All the client knows is that if he/she submits the above URL then a document containing the list of parts is returned. Since the implementation is transparent to clients, Parts Depot is free to modify the underlying implementation of this resource without impacting clients. This is loose coupling. Here's the document that the client receives:See less »
one sec please...
