ICCT Wiki

User Tools

Site Tools

Trace:
at-m42:lecture11

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
at-m42:lecture11 [2009/04/17 07:52] – eechrisat-m42:lecture11 [2011/01/14 12:45] (current) – external edit 127.0.0.1
Line 319: Line 319:
  
 **Notes**: Fielding was one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification. REST is a set of principles that define how Web standards, such as HTTP and URIs, are supposed to be used. If you adhere to REST principles you will end up with a system that exploits the Web's architecture to your benefit. **Notes**: Fielding was one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification. REST is a set of principles that define how Web standards, such as HTTP and URIs, are supposed to be used. If you adhere to REST principles you will end up with a system that exploits the Web's architecture to your benefit.
 +
 +===== Give every "thing" an ID =====
 +
 +On the web any individual object can have a URL:
 +  http://game.com/players/1234
 +  http://game.com/actions/2009/04/17/26
 +  http://game.com/items/4554
 +  http://game.com/processes/move/east
 +
 +But so can collections:
 +
 +  http://example.com/actions/2007/11
 +  http://example.com/items?weight=10 
 +
 +----
 +
 +This makes it easy for both web browsers and other programs to be able to find objects that need to be manipulated in a distributed system.
 +
 +===== Link things together =====
 +
 +Some made up XML:
 +  <inventory carrier='http://game.com/players/1234' > 
 +     <weight>120</weight> 
 +     <potency>12</potency>
 +     <item ref='http://games.com/items/4554' /> 
 +     <item ref='http://games.com/items/4556' /> 
 +  </order> 
 +
 +----
 +
 +Represents the inventory of a player in our game (could of course be HTML is a web application, but I wanted to emphasize machine-to-machine communication). Note that we are using familiar concept to link to define relationships. Thus to find out more, e.g. about one of the items being carried, the application can navigate to that resource via its URL.
 +
 +===== Use standard methods =====
 +
 +  * Traditional Service-Oriented Architecture: must use API as defined.
 +  * Might be implemented in RMI, CORBA, SOAP 
 +{{:at-m42:soa-game.png|A traditional Object-Based distributed game}}
 +
 +
 +
 +----
 +
 +You can see that there are two services defined here (without implying any particular implementation technology). The interface to these services is specific to the task -- it's a ''GameManagement'' and ''PlayerManagement'' service we are talking about. If a client wants to consume these services, it needs to be coded against this particular interface -- there is no way to use a client that was built before these interfaces were specified to meaningfully interact with them. The interfaces define the services' application protocol.
 +
 +===== RESTful services =====
 +
 +  * Must use ''verbs'' from the HTTP application protocol.
 +{{:at-m42:restful-game.png|}}
 +
 +----
 +
 +You can see that what have been specific operations of a service have been mapped to the standard HTTP methods -- and to disambiguate, we have created a whole set of new resources.
 +
 +Essentially, this makes your application part of the Web -- its contribution to what has turned the Web into the most successful application of the Internet is proportional to the number of resources it adds to it. In a RESTful approach, an application might add a few million game item URIs to the Web; if it’s designed the same way applications have been designed in CORBA times, its contribution usually is a single "endpoint" -- comparable to a very small door that provides entry to a universe of resource only for those who have the key.
 +
 +The uniform interface also enables every component that understands the HTTP application protocol to interact with your application. 
 +
 +To summarize: For clients to be able to interact with your resources, they should implement the default application protocol (HTTP) correctly, i.e. make use of the standard methods GET, PUT, POST, DELETE.
 +
 +===== Resources with multiple representations =====
 +
 +  * An HTTP client is expected to be able to handle multiple resources types and to make use of //content negotiation// to request a particular format:
 +
 +  GET /players/1234 HTTP/1.1
 +  Host: game.com 
 +  Accept: text/html
 +
 +  GET /players/1234 HTTP/1.1
 +  Host: game.com 
 +  Accept: application/atom+xml
 +
 +----
 +
 +There is a significant benefit of having multiple representations of a resource in practice: If you provide both an HTML and an XML representation of your resources, they are consumable not only by your application, but also by every standard Web browser — in other words, information in your application becomes available to everyone who knows how to use the Web.
 +
 +===== Communicate statelessly =====
 +  * HTTP is a //stateless// protocol: every request is a //new request//. 
 +  * Therefore state must be stored in the client or in the resources.
 +
 +===== Impact of REST =====
 +
 +  * World-wide web is built on a RESTful architecture, so you could argue that it's already proved its worth.
 +  * Becoming more popular for distributed computing: key feature of application frameworks like Rails and Grails.
 +  * Needs a rethink: away from traditional OO design based around a few nouns and a rich vocabulary of verbs to few verbs and many nouns.
  
 ===== Distributed Computing APIs ===== ===== Distributed Computing APIs =====
Line 361: Line 445:
   * If some part of the application uses legacy code or is not written in Java then use CORBA   * If some part of the application uses legacy code or is not written in Java then use CORBA
   * SOAP is a recent attempt to simplify distributed computing by use of XML and standard internet technologies like HTTP.   * SOAP is a recent attempt to simplify distributed computing by use of XML and standard internet technologies like HTTP.
-  * RESTful services recognizes that HTTP itself can provide many of the benefits of CORBA or SOAP a much lest cost.+  * RESTful services recognizes that HTTP itself can provide many of the benefits of CORBA or SOAP at much lest cost.
   * JINI is a networking technology that allows small applications or networked devices to communicate with other and dynamically configure themselves to create distributed applications.   * JINI is a networking technology that allows small applications or networked devices to communicate with other and dynamically configure themselves to create distributed applications.
 +
 +===== What Should You Remember? =====
 +
 +Apart from some special cases, current trend (as we'll see) is away from distributed computing using RMI, CORBA and SOAP towards a Web-Based architecture constructed from user-facing HTML clients consuming RESTful services over HTTP and with machine-to-machine communications exploiting XML resource exchange over HTTP. JINI is a niche technology that was in the doldrums for a long time. JNDI, RMI, and SOAP are still important in Enterprise Application Development, but over time, I would expect them to become relegated to very specialized "back office" applications. 
 +
  
 ---- ----
  
-[[Home]] | [[lecture10|Previous Lecture]] | [[Lectures]] | [[lecture11|Next Lecture]] +[[Home]] | [[lecture10|Previous Lecture]] | [[Lectures]] | [[part3|Next Lecture]] 
at-m42/lecture11.1239954732.txt.gz · Last modified: 2011/01/14 12:21 (external edit)