1 / 90

REST Architectural Style for Web Applications

Explore the fundamentals of REST and how it introduces an architectural style for web applications. Learn about resources, representations, communication, and the different models associated with REST.

dangie
Download Presentation

REST Architectural Style for Web Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. COMS E6125 Web-enHanced Information Management (WHIM) Prof. Gail Kaiser Spring 2012 Kaiser: COMS E6125

  2. Today’s Topic: • REST Architectural Style Kaiser: COMS E6125

  3. What Do We Mean By Architecture? • A software architecture investigates and determines methods for • how best to partition a system, • how components identify and communicate with each other, • how information is communicated, • how elements of a system can evolve independently, and • how all of the above can be described using formal and informal notations Kaiser: COMS E6125

  4. What Do We Mean By Architectural Style? • Common pattern across system architectures • A named, coordinated set of architectural constraints (analogous to “design patterns”) • Example architectural styles: client-server, N-tier, peer-to-peer, pipes, plugin • One system may be composed of multiple styles • Some styles are hybrids of other styles • REST (REpresentational State Transfer) introduces an architectural style for Web applications Kaiser: COMS E6125

  5. Why “Representational State Transfer”? • 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 the application by selecting links (state transitions), • resulting in the next page (representing the next state of the application) being transferred to the user agent, and • rendered for use Kaiser: COMS E6125

  6. REST Fundamentals • Resources • Representations of resources • Communication to obtain/modify representations • Web “page” as an instance of an application’s state • Engines to move from one state to the next (browser, spider, any media type handler) Kaiser: COMS E6125

  7. What is a Resource? • A resource can be anything that has identity • a document or image • a service, e.g., informing “today’s weather in Seattle” • a collection of other resources • non-networked objects (e.g., people) • The resource is the conceptual mapping to an entity or set of entities, not necessarily the entity that corresponds to that mapping at any particular point in time Kaiser: COMS E6125

  8. Representations of a Resource • The Web is designed to manipulate and transfer representations of a resource (not the actual resource) • A single resource may be associated with multiple representations (content negotiation) • A representation is in the form of a media type that provides meta-data information for this resource • Hypermedia-aware media types provide potential state transitions • Most representations are cacheable Kaiser: COMS E6125

  9. A Resource is Defined by a URI http://www.domain.com/name/of/resource?limit=10&offset=0#bookmark

  10. Resource Operations • Once the resource has been reached, it needs to be acted upon • Four simple verbs: GET, PUT, POST, DELETE • GET – read or query, no side-effects, cacheable, searchable • PUT and DELETE – atomically alter the state of the entire resource • POST – very generic, may alter internal state or behave like a remote procedure call Kaiser: COMS E6125

  11. Representational State Transfer • GET – transfers some representation from the server to the client, changing the state of the client (but not the server) • GET - Following a link in the representation transfers the client to another state • PUT, DELETE – transfers some representation from the client to the server, changing the state of the server • POST – transfers some content to the server, changing the state of the server Kaiser: COMS E6125

  12. Example RESTful API • https://dev.twitter.com/docs/api Kaiser: COMS E6125

  13. Representational State Transfer • Optimized for transfer of typed data streams • Caching of representations allows application interaction to proceed without using the network Kaiser: COMS E6125

  14. Origin Server Model • Server provides interface to services as a resource hierarchy • Implementation details hidden from clients • Stateless interaction for scalability • Application interaction can be spread across multiple servers • Replaceable by a gateway pipe Kaiser: COMS E6125

  15. Gateway Model • Appears as a normal origin server to client • Provides an interface encapsulating other services - data flow translation in both directions • Also used for high-speed caching Kaiser: COMS E6125

  16. Agent Model • Holds all application state • which allows user to manipulate it (history) • or anticipate changes to it (link maps) • Application details hidden from server • browser, spider, index robot, personal agent • Replaceable by a proxy pipe Kaiser: COMS E6125

  17. Proxy Model • Translate multiple services into HTTP • Transform data streams according to client limitations (e.g., image translation) • Enforce security policies • Enable shared caching Kaiser: COMS E6125

  18. Representational State Transfer • Optimized for transfer of typed data streams • Caching of representations allows application interaction to proceed without using the network Kaiser: COMS E6125

  19. Where Did REST Come From? • Defined in Roy Fielding’s PhD thesis (University of California at Irvine, 2000) • Who is this Roy Fielding? • Co-author of HTTP/1.0, URI standards • First author of HTTP/1.1 standard • Co-Founder of Apache • Now Chief Scientist of Day content management company Kaiser: COMS E6125

  20. Questions Fielding’s thesis tried to answer • How do we introduce a new set of functionality to an architecture that is already widely deployed? • How do we ensure that its introduction does not adversely impact, or even destroy, the architectural properties that have enabled it to succeed? Kaiser: COMS E6125

  21. REST is a Network Application Architecture • Communication is restricted to message passing • Defines • how system components are allocated and identified • how the components interact to form a system • the amount and granularity of communication needed for interaction • interface protocols • Usually highly concerned with performance issues Kaiser: COMS E6125

  22. Network Performance Measures • Latency • latent period: time between stimulus and first indication of a response • minimum latency = ping/echo time • Throughput • rate of data transfer • Round trips • number of interactions per user action Kaiser: COMS E6125

  23. Network Performance Measures • Overhead • setup: time to enable application-level interaction • message control • Amortization • spreading overhead across many interactions • Completion = setup / amortization+ (roundtrips * latency)+ (control + data) / throughput Kaiser: COMS E6125

  24. User-perceived Performance • User-perceived latency impacted by • setup overhead • network distance x round trips • blocking/multithreading • collisions • User-perceived throughput impacted by • available network bandwidth • message control overhead • message buffering, layer mismatches Kaiser: COMS E6125

  25. REST Goals • Scalability of component interactions • Generality of interfaces • Independent deployment of components • Intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems • REST Goals derived (in part) from original Web Requirements Kaiser: COMS E6125

  26. Low Entry-Barrier • For readers, authors and application developers • All protocols defined as text, so communication can be viewed and interactively tested using existing network tools • Enabled early adoption of the protocols to take place despite lack of standards Kaiser: COMS E6125

  27. Simple and general hypermedia user interface • Same interface can be used regardless of the information source • Flexibility of hypermedia relationships (links) allows for unlimited structuring • Direct manipulation of links allows complex relationships within the information to guide the reader through an application • Since information within large databases often easier to access via search rather than browsing, can also perform simple queries by providing user-entered data to a service and rendering the result as hypermedia Kaiser: COMS E6125

  28. Partial availability must not prevent content authoring • Authoring language needed to be simple and created using existing editing tools • Unavailability of some referenced information, either temporarily or permanently, should not prevent the reading and authoring of available information • Create references to information before the target of that reference is available • References needed to be easy to communicate, in email directions or written on a napkin Kaiser: COMS E6125

  29. Extensibility • Avoid getting stuck forever with the limitations of what was initially deployed • Requirements change over time Kaiser: COMS E6125

  30. Minimize Latency • Hypermedia involves application control information embedded within (or as a layer above) presentation information, which in distributed case may be stored at remote locations • User actions require transfer of large amounts of data from where stored to where used • Usability highly sensitive to user-perceived latency: time between selecting a link and rendering of a usable result • Thus, must minimize network interactions (round-trips within the data transfer protocols) Kaiser: COMS E6125

  31. Internet-scale • More than just geographical dispersion • Internet interconnects across multiple organizational boundaries Kaiser: COMS E6125

  32. Anarchic Scalability • Need for architectural elements to continue operating when they are subjected to an unanticipated load, or when given malformed or maliciously constructed data • Clients cannot maintain knowledge of all servers • Servers cannot retain knowledge of state across requests • Data elements cannot retain "back-pointers" for each element that references them Kaiser: COMS E6125

  33. Anarchic Scalability • Intermediary applications, such as firewalls, should be able to inspect the application interactions and prevent those outside the security policy of the organization • Participants should assume that any information received is untrusted, or require additional authentication before trust can be given • The architecture must be capable of communicating authentication data and authorization controls • Default operation should be limited to actions that do not need trusted data Kaiser: COMS E6125

  34. Independent Deployment • Be prepared for gradual and fragmented change, where old and new implementations co-exist • Architectural elements need to be designed with the expectation that later architectural features will be added • Older implementations need to be easily identified so that legacy behavior can be encapsulated without adversely impacting newer elements • Ease deployment in a partial, iterative fashion, since it is not possible to force deployment in an orderly manner Kaiser: COMS E6125

  35. Fielding’s Approach • Use an architectural style to define and improve the design rationale behind the Web's architecture • Use that style as the acid test for proving proposed extensions prior to their deployment (acid test = a foolproof test that will accurately determine the validity of something) Kaiser: COMS E6125

  36. Start with the “null” Style • No distinguished boundaries between components Kaiser: COMS E6125

  37. Add Client-Server • Emphasizes separation of concerns • Separate the user interface (client initiators) from data storage (server listeners) • improves portability of the user interface across multiple platforms • improves scalability by simplifying the server components (compared to console user interface) • Allows components to evolve independently Kaiser: COMS E6125

  38. Add Stateless Server • Client-server interaction must be stateless in nature • each request from client to server must contain all of the information necessary to understand the request • cannot take advantage of any stored context on the server • Session state is therefore kept entirely on the client Kaiser: COMS E6125

  39. Compare to Stateful Server • Each client initiates a session on server • Application state kept on server • Commands are used to exchange data orchange session state • Flexible, interactive, easy to extend services • Scalability is a problem Kaiser: COMS E6125

  40. Stateless Issues • Visibility improved because a monitoring system does not have to look beyond a single request in order to determine the full nature of the request • Reliability improved because eases the task of recovering from partial failures • Scalability improved because not having to store state between requests allows the server component to quickly free computing resources • Simplifies implementation because the server doesn't have to manage resource usage across requests Kaiser: COMS E6125

  41. Stateless Tradeoffs • May decrease network performance by increasing the repetitive data (per-interaction overhead) sent in a series of requests, since that data cannot be left on the server in a shared context • Placing application state on the client-side reduces the server's control over consistent application behavior, since the application becomes dependent on the correct implementation of semantics across multiple client versions Kaiser: COMS E6125

  42. Add Caches • Improves network efficiency • Requires that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable • If cacheable, then client cache is given the right to reuse that response data for later, equivalent requests Kaiser: COMS E6125

  43. Cache Tradeoffs • Potential to partially or completely eliminate some interactions, improving efficiency, scalability and user-perceived performance by reducing the average latency of a series of interactions • Can decrease reliability if stale data within the cache differs significantly from the data that would have been obtained had the request been sent to the server Kaiser: COMS E6125

  44. Pre-1994 Web Architecture Kaiser: COMS E6125

  45. Pre-1994 Web Architecture • Stateless client-server interaction for the exchange of static documents • Rudimentary support for non-shared caches • Relied on a common client-server implementation library (CERN libwww) to maintain consistency across Web applications Kaiser: COMS E6125

  46. But… • Developers of Web implementations had already exceeded the early design • Requests could identify services that dynamically generated responses, such as image-maps and server-side scripts • New intermediary components - proxies and shared caches - required protocol extensions to communicate reliably Kaiser: COMS E6125

  47. Add Uniform Interface • Apply principle of generality to the component interface, so overall system architecture is simplified and visibility of interactions is improved • Implementations are decoupled from the services they provide, which encourages independent evolvability Kaiser: COMS E6125

  48. Uniform Interface Tradeoffs • Degrades efficiency, since information is transferred in a standardized form rather than one specific to an application's needs • Efficient for large-grain hypermedia data transfer, optimizing for the Web common case, but resulting in an suboptimal interface for other architectural interactions Kaiser: COMS E6125

  49. Add Layers • Constrain component behavior such that each component cannot "see" beyond the immediate layer with which they are interacting • Places bound on the overall system complexity and promotes substrate independence Kaiser: COMS E6125

  50. Akin to Pipe-and-Filter • Data stream is filtered through a sequence of components • Components do not need to know identity of peers • Components are transitive Kaiser: COMS E6125

More Related