REST Architectural Style for Web Applications

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