Life on the Web is fast and furious should we be more RESTful?

Size: px

Start display at page:

Download "Life on the Web is fast and furious should we be more RESTful?"

Gordon Horton
5 years ago
Views:

1 Life on the Web is fast and furious should we be more RESTful? Gerhard Bayer Senior Consultant International Systems Group, Inc.

2 Agenda Today Overview of REST concepts The concept of resources The uniform interface Architectural constraints Exploiting HTTP What about business logic? RESTful vs. RESTlike systems Traditional Web Services vs. REST JSON vs. XML Why WSDL and the REST alternative Why SOAP and the REST alternative Perceived deficiencies of REST Technology support Conclusions 2

3 Representational State Transfer (REST) Architectural style for distributed hypermedia systems Prime example: the World Wide Web Originated in a 2000 doctoral dissertation by Roy Fielding One of the authors of the HTTP protocol specification Why REST? REST is based on the proven concepts of the WWW HTTP Hyperlinked resources Some high profile companies that are providing services in a REST form or tools to build RESTful services: Yahoo, ebay, Amazon, Google, IBM, Sun, Microsoft 3

4 Defining RESTful Architectures REST is an alternative to traditional Web Services Based on WSDL, SOAP, WS-* RESTful architectures are characterized by three key concepts: Resources that can be addressed through standard links A Uniform Interface based on HTTP Architectural constraints for resource implementations 4

5 The Concept of Resources A resource is an entity that can be accessed through a standard link REST prescribes using a Uniform Resource Identifier (URI) Allows to exploit the proven addressing scheme of the WWW The first step in designing a RESTful system is to define the URIs for all resources E.g. a reservation system might define individual reservations: For example reservation number : 5

6 Resources Should Exploit Hyperlinking A resource typically should include links to other resources For example, our reservation resource would include a link to the passenger(s): <reservation> <ID> </> <passenger ref= /> </reservation> A typically usage is a list resource that facilitates navigation among reservations: 6

7 Resources Should Exploit Hyperlinking RESTful systems take advantage of the Web addressing scheme This is very dynamic: the server can reside anywhere, and change location without affecting the clients This kind of addressing is standard, everybody understands it, and it is available everywhere Compare to finding objects Can exploit caching: Resource representations can be cached They are just data, e.g. XML Utilization of caching is what made the Web so extremely scalable 7

8 The Uniform Interface Client/server systems usually have custom interfaces Web Services typically expose custom operations E.g. the bank account Web Service interface is different from the rental car reservation Web Service interface Objects are called on their methods Classes define custom interfaces There is only one REST interface for all systems that follow this architectural style Consists of the HTTP commands: GET, PUT, POST, DELETE 8

9 The Uniform Interface Example: a REST-based travel agent application Each reservation is exposed through a URL A client application sends a PUT command to the application in order to create a new reservation It uses a GET command to a URL that identifies one particular reservation in order to retrieve it Then it might send POST against the same URL, including data in the body of the request that would change the reservation It uses DELETE to cancel the reservation 9

10 The Uniform Interface The HTTP commands can conceptually be mapped to the CRUD operations: CRUD HTTP Create PUT Read GET Update POST Delete DELETE 10

11 Traditional Web Service Interface vs. REST Reservation Service createreservation() getreservation() changereservation() cancelreservation() listreservations() listreservationsofcustomer() Customer Service createcustomer() getcustomerdetails() updatecustomer() deletecustomer() listcustomers() Interface Resource GET PUT POST DELETE /reservations GET list all reservations POST create reservation /reservations/(id) GET read reservation detail PUT change reservation DELETE cancel reservation /customers GET list all customers POST create customer /customers/(id) GET read customer detail PUT update customer DELETE delete customer /customers/(id)/reservations GET all customer reservations PUT add reservation to customer DELETE cancel all reservations11

12 Defining RESTful Architectures RESTful architectures are characterized by three key concepts: Resources that can be addressed through standard links A Uniform Interface based on HTTP Architectural constraints for resource implementations 12

13 Architectural Constraints REST prescribes an architectural constraint for the resources: Resources should not maintain state This is key for reliability and scalability When discussing state one has to distinguish between session state and server state Server state consists of persistent data that is kept on the server In a database, ERP system, etc. For example the balance of a bank account Session state describes the status of a session that a user (i.e. client application) maintains with an application Keeps track of a multi-step conversation between the user and the application 13

14 Architectural Constraints Many of today s Web applications violate this principle Session state is maintained on the server in memory E.g. a shopping cart The client passes a token that identifies the session state This design can not scale easily E.g. passing session state across servers in a cluster 14

15 Architectural Constraints Statelessness requires that the client passes sufficient conversational information with each request to the server application Stateless applications provide ultimate scalability Each request is independent of previous requests and can be handled by any available application instance Load balancing and failover are much easier to achieve 15

16 Designing A RESTful System The basic steps when designing a RESTful system are: Define the resources and assign URIs Define the data formats for input and output In REST this could be anything, for example XML, JSON, binary, etc. Company or particular vertical industry XML standards are obviously helpful Define what the HTTP verbs mean for each resource in terms of semantics This is often obvious Choose response codes HTTP has a comprehensive response code set to choose from 16

17 Exploiting HTTP RESTful systems exploit the Web, and in particular HTTP: Caching Redirection Compression Standard response codes Content negotiation - resources can, and should be, represented in different formats GET /reservations/ HTTP/1.1 Host: travelco.com Accept: application/custom-xml 17

18 What About Business Logic? REST is not just about data There could be a lot of business logic implementing a resource E.g. put together the resource state from legacy systems, databases, computations But some scenarios require actions Example: a currency converter CRUD is not enough We need to be able to request actions This is outside of standard REST There are different design approaches 18

19 What About Business Logic? Sample currency conversion resource: We could use a GET against this resource, or a POST there are no specific rules Another approach re-introduces the notion of interfaces, or not? No custom operations - still uses HTTP verbs, but includes some activity description E.g. Amazon EC2 uses GET to send a request for an activity that is embedded in the XML E.g. Action Run machine image People create XML based languages to describe activities 19

20 RESTful vs. RESTlike Systems Many systems are RESTlike, but not completely RESTful One example of a RESTlike system is the B2B Gateway that we have built for one of our customers: The B2B Gateway receives reservations from a multitude of B2B partners and acts as a conduit to a back office reservations application The system supports the following functionality: Create Reservation Modify Reservation Retrieve Reservation Cancel Reservation Quote Price 20

21 Sample RESTlike System Architecture Business Partners Vettro GT3 Future Partners Sockets, Web Service (HTTP) Orchestration Services Application Services Vettro Inbound Request Service GT3 Reservation Request Service GT3 Customer Cancel Service CSI Reservation CSI Reservation CSI Services Reservation CSI Services Reservation CSI Services Reservation CSI Services Reservation Services Services Reservation Service Wrapper Invoice Service City of Service Calculation Infrastructure Services Message Store Communication Notification Transformation Security 21

22 Sample RESTlike System The B2B Gateway has been designed in a RESTlike fashion: It is not completely REST since it doesn t utilize the HTTP commands correctly All services are based on the HTTP Post command The requested function could be embedded in the XML payload of the request Something like POST reservation_service (xml (action=cancel)) In the current design it is inherent in the service Something like POST cancel_reservation_service (xml) This Cancel Reservation Service should rather be a reservation resource that accepts HTTP Delete Similarly, the Retrieve Reservation Service should be a reservation resource that accepts HTTP Get 22

23 Sample RESTlike System The B2B Gateway has been designed in a RESTlike fashion (cont.): It does not follow a strict addressing of resources based on URIs It doesn t exploit the standard HTTP response codes This had been dictated by the requirement to follow an industry standard 23

24 Traditional Web Services vs. REST Characteristics of traditional Web Services based architectures XML is used for data exchange between service provider and service consumer Binary data can be encapsulated within an XML envelope Requires encoding (i.e. Base64) of the data such that the service consumer understands how to deal with it This increases transmission size and creates processing overhead for the encoding and decoding REST is based on HTTP, which allows content negotiation, and thus can use any data format E.g. JSON (JavaScript Object Notation) has become a popular format for Rich Internet Applications (RIAs) that are based on Ajax 24

25 JavaScript Object Notation (JSON) Typical (RIA) Web application architecture: User interaction Ajax Browser JSON OR XML? RESTful Web Service Web Service Platform JavaScript Object Notation (JSON) alternative format to XML 25

26 JSON vs. XML XML is difficult to process within the Browser Typically requires complex DOM programming E.g. many method calls navigating through the nodes of the DOM data tree Often introduces cross-browser compatibility issues JSON as an alternative Leverages the fact that JavaScript is available in all mainstream Browsers And it is a popular client side development tool JSON is a data format that is natural to JavaScript Uses a textual data representation On first glance similar to XML However, much easier to process in JavaScript 26

27 JSON vs. XML passenger": {"name": Jo D", "address": { "street": 100 Broadway" "city": New York", "zip": 10101, }, "phones": [ ", " ] <passenger> <name>jo D</name> <address> <street>100 Broadway</street> <city zip= 10101">New York</city> <phonenumbers> <phone> </phone> <phone> </phone> </phonenumbers> </address> </passenger> 27

28 Why WSDL And The REST Alternative Interface description WSDL is used as the formal, standard language to describe The service interface The concrete (physical) binding to a service implementation The biggest part of the service interface description is about the data types that the service expects However, data types are usually described in an XML Schema, separate from the WSDL 28

29 WSDL + XML Schema When WSDL is used to describe the interface of a Web Service, the parameters of each operation need to be defined Requires type definitions There are 3 options for type definitions in WSDL Define all types explicitly in the type section of the WSDL No types should be defined in reusable Schemas Define types in a Schema and reference needed elements individually in WSDL No unnecessary duplication Define all types in a Schema and reference the entire schema in WSDL as a complex type 29

30 WSDL + XML Schema Define all types explicitly in the type section of the WSDL: <types> <xsd:schema <xsd: element name= CreateReservationType > <xsd:complextype> <xsd:sequence> <xsd:element name= ="PickUpDateAndTime" type="xs:datetime /> <xsd:element name= ="PickUpLocation" type="xs:string /> </xsd:sequence> </xsd:complextype> </xsd: element> </xsd:schema> </types> These types are then referenced in the message section of the WSDL 30

31 WSDL + XML Schema Define all types in Schema and reference the entire Schema as complex type in WSDL: <types> <xsd:schema <xsd:import.. import the Schema here. <xsd: element name= CreateReservationType > <xsd:complextype> <xsd:sequence> <xsd:element name= Create type= CreateReservation /> </xsd:sequence> </xsd:complextype> </xsd: element> </xsd:schema> </types> Again, this type is then referenced in the message section of the WSDL 31

32 Why WSDL And The REST Alternative REST alternative: REST is based on the concept of resources Resources can be described using XML Schemas Often clients and resource in a RESTful architecture exchange data encoded in other formats E.g. JSON format - JavaScript Object Notation There is no XML involved 95% of what WSDL defines is already available in XML Schemas The rest deals with operations, protocol binding, and non-essential items 32

33 Why WSDL And The REST Alternative Definition of operations WSDL allows defining several proprietary operations that a Web Service supports For example, a flight reservation Web Service might expose an interface with the operations create reservation, modify reservation, and cancel reservation Related functions are usually grouped as operations into one service E.g. organized by business domain, geography, security constrains, etc. To add another function to a service, the WSDL has to be changed and provided to the service consumers In addition to the Schemas that define the data of the new function extensibility? 33

34 Why WSDL And The REST Alternative REST alternative: REST uses only the standard operations defined in the HTTP specification (Get, Post, etc.) A description of operations is therefore not necessary Covers a large percentage of possible requirements Some requirements cannot be satisfied with this approach; typically solved by passing command strings to the application 34

35 Why WSDL And The REST Alternative Endpoint definition A client that wants to access a Web Service needs to know its physical address WSDL allows the formal definition of such an endpoint Traditional Web Services do not follow the Web concept of hyperlinked resources They typically make RPC calls like in programming languages Clients need to obtain and parse the WSDL in order to find the service address So what is Web about Web Services? REST alternative: RESTful resources are addressable through URIs This follows the standard mechanism of the Web 35

36 Why WSDL And The REST Alternative Protocol binding WSDL allows defining which protocol (i.e. SOAP or HTTP) should be used to access a Web Service It also defines how in particular this protocol should be used REST alternative: In a REST scenario, HTTP is the standard protocol 36

37 Why WSDL And The REST Alternative Client code generation WSDL can be used as input to tools that generate code for building Web Service clients This is mostly beneficial for RPC-style invocation of Web Services REST alternative: REST does not require building interface specific client code 37

38 Why WSDL And The REST Alternative Business process management: WSDL is a requirement for linking BPEL based business processes to services SOAP is typically used by the BPEL engine to communicate with a Web Service REST alternative: The Web Service Invocation Framework (WSIF) provides a solution for services that do not follow the WSDL/SOAP paradigm WSDL needs to be created to describe the service WSIF supports a multitude of communication mechanisms beyond SOAP 38

39 Why SOAP And The REST Alternative Advantages of SOAP Most of the higher-layer WS*- standards are based on utilizing the SOAP header BUT: Which standards are really required for your project? Often used in RPC-style service invocation Disadvantages of SOAP Adds another layer of complexity Service consumer and provider are (in most cases) already connected through HTTP Many requirements that typically lead to using the WS* standards can be addressed by proper application design RPC-style service invocation results in tight coupling of the Web Service provider and consumer 39

40 Which Standards Do You Really Need? BPEL4People Internet Monitoring & Management BPM CEP BAM B2B BPEL/BPMN WS-I Messaging WS-Reliable Messaging WS-Notification Security Transform WS-Security XSLT Route XML Transact Oasis Protocol Switching HTTP, TCP, FTP, JMS, SOAP, etc. XML XML-Schema XML WSIF Service Consumer Service Registry Wrapper WSDL Legacy Systems, Packages, New Services UDDI Service Providers 40

41 Perceived Deficiencies of REST Transactions Transactions for traditional Web Services have been defined by OASIS Tries to implement distributed all or nothing transactions through SOAP wrappers for the XA protocol A business activity cannot be completed unless all participating resources are updated successfully or rolled back to a previous consistent state Requires locking of resources Not feasible across the Internet Even within the boundaries of one company, the notion of Web Services assumes much less control over the execution behavior than in case of the tightly coupled systems that gave rise to XA 41

42 Perceived Deficiencies of REST Compensating transactions: B2B (and some times A2A) integration often requires support for long running transactions E.g. making reservations for airline, hotel, and rental car as one combined transaction It could take hours or days for all participating resources to complete the transaction In the Web Services standards they are also called Business Transactions (BT) Prohibitive to lock resources + cannot assume eventual successful updates Failure handling through compensating transactions The consistency of all participating systems is restored by running transactions that turn back the effect of the initial transactions 42

43 Perceived Deficiencies of REST Reliable message delivery WS-Reliability provides message delivery assurances: At most once, at least once, exactly once In order Several messages belonging to one sequence are delivered to the service provider in the same order they were sent by the service consumer REST alternative: Some applications can simply resend a message, without causing problems if the receiver gets it twice E.g. send the latest stock price Using an application level protocol to acknowledge message receipt is often a better choice anyway Message has been delivered vs. has been understood 43

44 Perceived Deficiencies of REST Publish / subscribe In a pub/sub model, an interested party subscribes to a particular category of information and gets notified each time this information is updated The WS-Notification specification supports pub/sub in the following ways: Direct communication between participants in a publish/subscribe environment Brokered communication XML based topic definition 44

45 Perceived Deficiencies of REST Publish / subscribe REST is fundamentally based on a client-server model HTTP always refers to a client and a server as the endpoints of communication Notification functionality can be implemented through polling E.g. RSS, Atom feeds This works well in some scenarios, but not all For example a large number of very distributed subscribers They use GET, which is a highly optimized operation on the Web Exploits caching, the scalability of the Web: the number of subscribers can be unlimited It would be less scalable to have the publisher send out notifications to all subscribers 45

46 Perceived Deficiencies of REST Asynchronous interactions A client issues a request against a server application and wants to obtain the result later Usually because the server takes a while for processing This problem can be solved conceptually the same way as in other environments (e.g. components): Use HTTP response code 202 (Accepted) Defined as The request has been accepted for processing, but the processing has not been completed. Obtain the result using either of 2 options: Through polling a different result URI returned by the server application By providing a URI to server where it can POST the result resource (this could also be used to build a pub/sub solution, see previous slide) 46

47 Security Perceived Deficiencies of REST In traditional Web Services, SOAP headers are used for a variety of security standards In RESTful systems, HTTP provides a number of options to implement security: Encryption Certificates Authentication and authorization HTTP provides less security options than SOAP, but for many application requirements it is sufficient 47

48 Registry Perceived Deficiencies of REST Where do you start, what is the entry point, how do you find things? In WSDL/SOAP based systems the entry point is the registry UDDI standard Finding a service endpoint in a registry is a non-trivial task In REST the general idea is that we don t need a registry Inherent concept of the hypermedia architecture is the notion of collections A collection is a list of links to other resources Remember our example of the reservations list There are some standards: Atom 48

49 Technology Support The technology support for building RESTful systems is growing Java example: JAX-RS Objective: map the REST principles to Java Developers don t have to code the mapping For example in a /helloworld ) public class text/plain ) public String sayhello() { return Hello World\n text/hml ) public String sayhelloinhtml() { return <html><title>hello World</title></html> } 49

50 Technology Support Examples: Sun reference implementation of JAX-RS: Jersey JBoss: RESTEasy Ruby, Python 50

51 Conclusions Traditional Web Services are not really Web They do not exploit the proven capabilities of the Web and HTTP Resources accessible through standard HTTP commands vs. services with proprietary interfaces Features of HTTP like scalability, content negotiation Hyper-linking of resources RESTful systems have gained mind share But: be aware of the deficiencies No equivalent support like WS-* standards But what do you really need for your application requirements? There is no standard approach to exposing business logic But for most application requirements REST is sufficient and there are a variety of approaches for exposing business logic 51

RESTful Services. Distributed Enabling Platform

RESTful Services. Distributed Enabling Platform RESTful Services 1 https://dev.twitter.com/docs/api 2 http://developer.linkedin.com/apis 3 http://docs.aws.amazon.com/amazons3/latest/api/apirest.html 4 Web Architectural Components 1. Identification: