Life on the Web is fast and furious – should we be more ... · PDF fileLife on the Web...

International SOA Conference 2009

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

Gerhard Bayer

Senior Consultant

International Systems Group, Inc.

[email protected]

http://www.isg-inc.com

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

3


Representational State Transfer (REST)

� Architectural style for distributed hypermediasystems � 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

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

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:

� http://www.company.com/reservation/(id)

� For example reservation number 012345:

� http://www.company.com/reservation/012345

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):

� A typically usage is a list resource that facilitates navigation among reservations:

� http://www.company.com/reservation-list

<reservation>

<ID>123456789</>

<passenger ref=“http:// www.company.com/passenger/0123”/>

</reservation>

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

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

9



� 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

10



� The HTTP commands can conceptually be mapped to the CRUD operations:

DELETEDelete

POSTUpdate

GETRead

PUTCreate

HTTPCRUD

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)/reservationsGET – all customer reservations

PUT – add reservation to customer

DELETE – cancel all reservations

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

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

14



� 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

15



� 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

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

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/012345 HTTP/1.1Host: travelco.comAccept: application/custom-xml

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

19


What About Business Logic?

� Sample currency conversion resource:

� http://currency.com/convert?dollar=20&euro=0

� 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

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

21


Sample RESTlike System – Architecture

CSI Reservation

Services

CSI Reservation

Services

CSI Reservation

Services

CSI Reservation

Services

CSI Reservation

Services

Business Partners

Vettro Inbound Request Service

GT3 Reservation

Request Service

GT3 Customer

Cancel Service

CSI Reservation

Services

Reservation Service Wrapper

City of Service

Calculation

Infrastructure Services

Orchestration Services Application Services

Vettro GT3Future

Partners

Sockets, Web Service (HTTP)

Message Store SecurityCommunication Notification Transformation

Invoice Service

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

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

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

25


JavaScript Object Notation (JSON)

� Typical (RIA) Web application architecture:

� JavaScript Object Notation (JSON) – alternative

format to XML

Ajax

BrowserWeb Service

Platform

RESTful Web

Service

JSON

User interaction

XML?

OR

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

27


JSON vs. XML

“passenger": {"name": “Jo D",

"address": {

"street": “100 Broadway"

"city": “New York",

"zip": 10101,

},

"phones": [

“212 489-0400",

“212 489-1125" ]

<passenger>

<name>Jo D</name>

<address>

<street>100 Broadway</street>

<city zip=“10101">New York</city>

<phoneNumbers>

<phone>212 489-0400</phone>

<phone>212 489-1125</phone>

</phoneNumbers>

</address>

</passenger>

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

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

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

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

32



� 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

33



� 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?

34




� 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

35



� 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?


� RESTful resources are addressable through URIs

� This follows the standard mechanism of the Web

36



� 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


� In a REST scenario, HTTP is the standard protocol

37



� 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 does not require building interface specific client code

38



� 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


� 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

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

40


Which Standards Do You Really Need?

Service Consumer

Service Registry

Service ProvidersUDDI

WrapperLegacy Systems, Packages, New

ServicesWSDL

BPEL/BPMN

XML XML-Schema

BPEL4People

BAMCEP

TransformMessaging

XSLT

XML

WS-Reliable Messaging

Route

XMLWS-Notification

Security

WS-Security

BPM

Protocol Switching HTTP, TCP, FTP, JMS, SOAP, etc.

Monitoring & Management

B2B

WSIF

Internet

WS-I

Transact

Oasis

41


Perceived Deficiencies of REST

� Transactions

� Transactions for traditional Web Services have been

defined by OASIS

� Tries to implement distributed “all or nothing” transactionsthrough 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

42



� 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

43



� 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


� 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”

44



� 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

45



� 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

46



� 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)

47



� Security

� 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

48



� Registry

� 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

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 servlet

@Path(“/helloworld“)

public class HelloWorldResource {

@GET @Produces(“text/plain“)

public String sayHello() {

return “Hello World\n“; }

@GET @Produces(“text/hml“)

public String sayHelloInHtml() {

return “<html><title>Hello World</title></html> }

50


Technology Support

� Examples:

� Sun reference implementation of JAX-RS: Jersey

� JBoss: RESTEasy

� Ruby, Python

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

Life on the Web is fast and furious – should we be more ... · PDF fileLife on the Web...

Documents

Transcript of Life on the Web is fast and furious – should we be more ... · PDF fileLife on the Web...