You are on page 1of 83

A Pragmatic

Introduction to REST
QCon London 2008
Stefan Tilkov, stefan.tilkov@innoq.com

Copyright innoQ 2008. All rights reserved.

1
Stefan Tilkov
http://www.innoQ.com
stefan.tilkov@innoq.com
http://www.innoq.com/blog/st/

http://www.InfoQ.com

Copyright innoQ 2008. All rights reserved.

2
REST vs. ... ?
Copyright innoQ 2008. All rights reserved.

3
REST vs. SOAP?
REST vs. SOA?
REST vs. WS-*?

Copyright innoQ 2008. All rights reserved.

4
Not today

Copyright innoQ 2008. All rights reserved.

5
(At least we’ll try)

Copyright innoQ 2008. All rights reserved.

6
First, let’s define some
things

Copyright innoQ 2008. All rights reserved.

7
What is SOA?

Copyright innoQ 2008. All rights reserved.

8
3 Possible Definitions

Copyright innoQ 2008. All rights reserved.

9
Take your pick

Copyright innoQ 2008. All rights reserved.

10
1

Copyright innoQ 2008. All rights reserved.

11
SOA: An Approach to
Business/IT Alignment
A different approach to an enterprise’s IT
architecture ...
... driven by business, not technology
... focusing on shared and re-used functionality
... aligning business and IT
... relying on strong governance

Copyright innoQ 2008. All rights reserved.

12
SOA: An Approach to
Business/IT Alignment

... can be implemented using any architecture,


technology, or set of products

Copyright innoQ 2008. All rights reserved.

13
2

Copyright innoQ 2008. All rights reserved.

14
SOA: A Technical
Architecture
Services with clearly defined interfaces
... autonomous and with explicit boundaries
... relying on shared schema, not shared code
... programming language-independent
... separating interface and implementation
... containing multiple specific operations

Copyright innoQ 2008. All rights reserved.

15
SOA: A Technical
Architecture

… somewhat technology-independent – can be


built with e.g. CORBA, DCE RPC, DCOM, RMI,
or Web services.

Copyright innoQ 2008. All rights reserved.

16
3

Copyright innoQ 2008. All rights reserved.

17
SOA = Web Services
Business data as XML messages
... sent in a SOAP body
... enriched with metadata in SOA headers
... described with WSDL and XML Schema
... configured through WS-Policy
... registered in a UDDI registry

Copyright innoQ 2008. All rights reserved.

18
SOA = Web Services
... implemented using technologies and products
from the WS-* universe

Copyright innoQ 2008. All rights reserved.

19
Web Services Standards Overview Dependencies

© innoQ Deutschland GmbH. All Rights Reserved. The poster may also contain references to other company, organisation, brand and product names. These company, organisation, brand and product names are used herein for identification purposes only and may be the trademarks of their respective owners.
Messaging Specifications
SOAP 1.1

Interoperability Business Process Specifications Management Specifications Presentation


SOAP 1.2

SOAP Message Transmission Optimization Mechanism

Issues Specifications
WS-Notification

Business Process Execution WS-Choreography Model Web Service Choreography Web Service Choreography Management Using Web Management Of WS-BaseNotification
WS-Management

Metadata
Resource

Security
Language for Web Services 1.1 Overview Interface Description Language Services (WSDM-MUWS) Web Services (WSDM-MOWS) AMD, Dell, Intel, Microsoft and Sun WS-Topics
(BPEL4WS) · 1.1 · BEA Systems, IBM, (WSCI) · 1.0 · W3C 1.0 1.0 Microsystems
1.0 · W3C (CDL4WS) · 1.0 · W3C WS-BrokeredNotification
Microsoft, SAP, Sun Microsystems, SAP, BEA Systems OASIS OASIS Published Specification Web Services for Remote
Working Draft Candidate Recommendation
Basic Profile Siebel Systems · OASIS-Standard and Intalio · Note OASIS-Standard OASIS-Standard
Portlets (WSRP) WS-Addressing – Core
1.1
WS-I ! Business Process Execution Language for Web Services ! WS-Choreography Model Overview defines the format ! Web Service Choreography Interface (WSCI) describes ! Web Service Choreography Description Language ! Web Service Distributed Management: Management Using ! Web Service Distributed Management: Management Of ! WS-Management describes a general SOAP-based 2.0 WS-Addressing – WSDL Binding
1.1(BPEL4WS) provides a language for the formal and structure of the (SOAP) messages that are exchanged, how Web Service operations can be choreographed in the (CDL4WS) is to specify a declarative, XML based language Web Services (WSDM-MUWS) defines how an IT resource Web Services (WSDM-MOWS) addresses management of protocol for managing systems such as PCs, servers, OASIS
Final Specification specification of business processes and business interaction and the sequence and conditions in which the messages context of a message exchange in which the Web Service that defines from a global viewpoint the common and connected to a network provides manageability interfaces the components that form the network, the Web services devices, Web services and other applications, and other
protocols using Web Services. are exchanged. participates. complementary observable behaviour, where message such that the IT resource can be managed locally and from endpoints, using Web services protocols. manageable entities. Committee Draft WS-Addressing – SOAP Binding
exchanges occur, and when the jointly agreed ordering remote locations using Web services technologies.
! Basic Profile – The Basic Profile 1.1 provides rules are satisfied. " Web Services for Remote Portlets (WSRP) defines a WS-Eventing
implementation guidelines for how related set of non-
proprietary Web Service specifications should be used Business Process Execution Business Process Management XML Process Definition
set of interfaces and related semantics which standardize
interactions with components providing user-facing WS-Enumeration
together for best interoperability. Language for Web Services 2.0 Language (BPML) Language (XPDL) Service Modeling Language markup, including the processing of user interactions with
that markup.
(BPEL4WS) · 2.0 1.1 IBM, BEA, BMC, Cisco, Dell, HP, Intel,
Metadata Specifications
2.0
OASIS, BEA Systems, IBM, Microsoft, SAP, BPMI.org Microsoft, Sun
Final
Siebel Systems · Committee Draft Final Draft Draft Specification
Basic Profile
1.2 ! Business Process Execution Language for Web Services ! Business Process Management Language (BPML) ! XML Process Definition Language (XPDL) provides an WS-Policy
2.0 (BPEL4WS) provides a language for the formal provides a meta-language for expressing business XML file format that can be used to interchange process ! Servcie Modeling Language (SML) is used to model
WS-I specification of business processes and business interaction processes and supporting entities. models between tools. complex IT services and systems, including their structure, WS-PolicyAssertions
Working Group Draft protocols using Web Services.

Security
constraints, policies, and best practices.
WS-PolicyAttachment
! Basic Profile – The Basic Profile 1.2 builds on Basic Profile

Messaging
1.1 by incorporating Basic Profile 1.1 errata, requirements WS-Discovery
from Simple SOAP Binding Profile 1.0, and adding support
for WS-Addressing and MTOM. WS-MetadataExchange

Universal Description, Discovery and Integration

Web Service Description Language 1.1


Basic Profile
Web Service Description Language 2.0 Core

Metadata Specifications Reliability Security Specifications Transaction Resource


2.0
WS-I
Working Group Draft Web Service Description Language 2.0 SOAP Binding

! Basic Profile – The Basic Profile 2.0 is an update of WS-I


BP that includes a profile of SOAP 1.2.
WS-Policy WS-PolicyAssertions Specifications WS-Security WS-SecurityPolicy Specifications Specifications Security Specifications
1.1 1.1 WS-Security
1.5 1.1
BEA Systems, IBM, Microsoft,
W3C
IBM, Microsoft, SAP
OASIS
RSA Security, VeriSign WS-Coordination Web Services WS-Security: SOAP Message Security
Attachments Profile Working Draft
Public Draft WS-ReliableMessaging OASIS-Standard
Public Draft 1.1 Resource Framework (WSRF)
1.0 1.1 OASIS WS-Security: Kerberos Binding
1.2
WS-I ! WS-Policy describes the capabilities and constraints of ! WS-PolicyAssertions provides an initial set of assertions OASIS ! WS-Security is a communications protocol providing a ! WS-SecurityPolicy defines how to describe policies related Working Draft OASIS
Final Specification the policies on intermediaries and endpoints (e.g. business to address some common needs of Web Services Committee Draft means for applying security to Web Services. to various features defined in the WS-Security specification. WS-Security: SAML Token Profile

Messaging
OASIS-Standard

Reliability

Metadata
rules, required security tokens, supported encryption applications. ! WS-Coordination describes an extensible framework for providing
algorithms, privacy rules). protocols that coordinate the actions of distributed applications. ! Web Services Resource Framework (WSRF) defines a family of WS-Security: X.509 Certificate Token Profile
! Attachments Profile – The Attachment Profile 1.0 specifications for accessing stateful resources using Web Services.
complements the Basic Profile 1.1 to add support ! WS-ReliableMessaging describes a protocol that allows
WS-Business Activity WS-Security: Username Token Profile
for interoperable SOAP Messages with attachments-based
Web Services.
Web services to communicate reliable in the presence of
software component, system, or network failures. It defines WS-Security: WS-Security: 1.1 WS-BaseFaults (WSRF) WS-SecurityPolicy
a SOAP binding that is required for interoperability. SOAP Message Security Username Token Profile OASIS 1.2
WS-PolicyAttachment WS-Discovery 1.1 1.1 Working Draft OASIS WS-Trust
1.2 Microsoft, BEA Systems, Canon, OASIS OASIS Working Draft
! WS-Business Activity provides the definition of the business activity
Simple SOAP W3C Intel and webMethods WS-Reliable Messaging Public Review Draft Public Review Draft coordination type that is to be used with the extensible coordination WS-Federation
! WS-BaseFaults (WSRF) defines a base set of information
Binding Profile W3C Member Submission Draft Policy Assertion (WS-RM Policy) framework described in the WS-Coordination specification. that may appear in fault messages. WS-BaseFaults defines an WS-SecureConversation
1.0 ! WS-Security: SOAP Message Security describes ! WS-Security: Username Token Profile describes how XML schema type for base faults, along with rules for how
1.1
WS-I
! WS-PolicyAttachment defines two general-purpose ! WS-Discovery defines a multicast discovery protocol for OASIS
enhancements to SOAP messaging to provide message
integrity and confidentiality. Specifically, this specification
a Web Service consumer can supply a Username Token as a
means of identifying the requestor by username, and
WS-Atomic Transaction this base fault type is used and extended by Web Services.
Final Specification

! Simple SOAP Binding Profile – The Simple SOAP Binding


mechanisms for associating policies with the subjects to
which they apply; the policies may be defined as part
of existing metadata about the subject or the policies may
dynamic discovery of services on ad-hoc and managed
networks.
Committee Draft provides support for multiple security token formats, trust
domains, signature formats and encryption technologies.
The token formats and semantics for using these are
optionally using a password (or shared secret, etc.) to
authenticate that identity to the Web Service producer.
1.1
OASIS
Committee Draft
WS-ServiceGroup (WSRF)
1.2
Reliability Specifications
! Web Services ReliableMessaging Policy Assertion

Basic Profile
Transaction
Profile consists of those Basic Profile 1.0 requirements be defined independently and associated through an defined in the associated profile documents. OASIS

Metadata
(WS-RM Policy) describes a domain-specific policy assertion WS-ReliableMessaging

Security
related to the serialization of the envelope and its external binding to the subject. ! WS-Atomic Transaction defines protocols that enable existing
representation in the message.
for WS-ReliableMessaging that that can be specified within
transaction processing systems to wrap their proprietary protocols
Working Draft
a policy alternative as defined in WS-Policy Framework.
and interoperate across different hardware and software vendors. WS-Reliability
! WS-ServiceGroup (WSRF) defines a means by which Web
WS-MetadataExchange Universal Description, WS-Security: WS-Federation Services and WS-Resources can be aggregated or grouped
1.1 WS-Composite Application together for a domain specific purpose. WS-Reliable Messaging Policy Assertion
Discovery and Integration (UDDI) Kerberos Binding 1.0
Framework (WS-CAF)
Basic Security Profile BEA Systems, Computer Associates,
3.0.2 WS-Reliability 1.0 IBM, Microsoft, BEA Systems, WS-ResourceProperties
1.0
WS-I
IBM, Microsoft, SAP, Sun Microsystems and
webMethods
Public Draft
OASIS
OASIS-Standard
1.1
OASIS
Microsoft, IBM, OASIS
Working Draft
RSA Security, and VeriSign
Initial Draft
1.0 · Arjuna Technologies, Fujitsu, IONA,
Oracle and Sun Microsystems
Committee Specification
1.2
OASIS
Resource Specifications
Board Approval Draft OASIS-Standard Working Draft
! WS-MetadataExchange enables a service to provide ! Universal Description, Discovery and Integration (UDDI) ! WS-Security: Kerberos Binding defines how to encode ! WS-Federation describes how to manage and broker the ! WS-Composite Application Framework (WS-CAF) is a Web Service Resource Framework
metadata to others through a Web services interface. Given defines a set of services supporting the description Kerberos tickets and attach them to SOAP messages. As trust relationships in a heterogeneous federated collection of three specifications aimed at solving problems ! WS-ResourceProperties specifies the means by which the
! Basic Security Profile defines the WS-I Basic Security only a reference to a Web service, a user can access a set and discovery of businesses, organizations, and other Web ! WS-Reliability is a SOAP-based protocol for exchanging well, it specifies how to add signatures and encryption to the environment including support for federated identities. that arise when multiple Web Services are used in combina- definition of the properties of a WS-Resource may be declared WS-BaseFaults
Profile 1.0, based on a set of non-proprietary Web services of WSDL /SOAP operations to retrieve the metadata that services providers, the Web services they make available, SOAP message, in accordance with WS-Security, which tion. It proposes standard, interoperable mechanisms for

Transaction
SOAP messages with guaranteed delivery, no duplicates, as part of the Web Service interface. The declaration of the

Messaging
specifications, along with clarifications and amendments describes the service. and the technical interfaces which may be used to access uses and references the Kerberos tokens. managing shared context and ensuring business processes
and guaranteed message ordering. WS-Reliability is WS-Resource properties represents a projection of or a view WS-ServiceGroup

Security
to those specifications which promote interoperability. those services. defined as SOAP header extensions and is independent of achieve predictable results and recovery from failure. on the WS-Resource state.
the underlying protocol. This specification contains a WS-ResourceProperties
binding to HTTP. WS-Context (WS-CTX) WS-ResourceLifetime
Web Service Description Web Service Description WS-Security: WS-Trust 1.0 1.2
WS-ResourceLifetime
REL Token Profile Language 2.0 Language 2.0 Core SAML Token Profile BEA Systems, Computer Associates, IBM, Layer 7 Arjuna Technologies, Fujitsu, IONA, Oracle OASIS

This poster is not to be reproduced or transmitted in any form or for any purpose without the express permission of innoQ Deutschland GmbH. · Copyright
Technologies, Microsoft, Netegrity, Oblix, WS-Transfer
1.0 SOAP Binding 2.0 1.1 OpenNetwork, Ping Identity Corporation,
and Sun Microsystems
Committee Draft
Working Draft
WS-I 2.0 W3C OASIS Reactivity, RSA Security, VeriSign and Westbridge Resource Representation SOAP Header Block (RRSHB)
Working Group Draft Candidate Recommendation Public Review Draft ! WS-ResourceLifetime is to standardize the terminology,
W3C · Working Draft Technology · Initial Draft ! WS-Context (WS-CTX) is intended as a lightweight mechanism concepts, message exchanges, WSDL and XML needed to
for allowing multiple Web Services to share a common context.

Management Specifications
monitor the lifetime of, and destroy WS-Resources.
! Web Service Description Language SOAP Binding ! Web Service Description Language 2.0 Core is an XML- ! WS-Security: SAML Token Profile defines the use of ! WS-Trust describes a framework for trust models that enables Additionally, it defines resource properties that may be used
! REL Token Profile is based on a non-proprietary
Web services specification, along with clarifications and
describes the concrete details for using WSDL 2.0 in based language for describing Web services and how to Security Assertion Markup Language (SAML) v1.1 assertions Web Services to securely interoperate. It uses WS-Security base WS-Coordination to inspect and monitor the lifetime of a WS-Resource.
conjunction with SOAP 1.1 protocol. access them. It specifies the location of the service and the in the context of WSS: SOAP Message Security including mechanisms and defines additional primitives and extensions
amendments to that specification which promote Framework (WS-CF)

Meta
operations (or methods) the service exposes. for the purpose of securing SOAP messages and SOAP for security token exchange to enable the issuance and
interoperability. message exchanges. dissemination of credentials within different trust domains. 1.0 · Arjuna Technologies, Fujitsu, IONA, WS-Transfer WS-Management

Messaging
Security
Oracle and Sun Microsystems W3C
Management Of Web Services
Committee Draft W3C Member Submission

Resource
Web Service Description WS-Security: X.509 WS-SecureConversation ! WS-Coordination Framework (WS-CF) allows the Management Using Web Services
SAML Token Profile BEA Systems, Computer Associates, IBM, management and coordination in a Web Services interaction ! WS-Transfer describes a general SOAP-based protocol for
1.0 Language 1.1 Certificate Token Profile Layer 7 Technologies, Microsoft, Netegrity, of a number of activities related to an overall application. accessing XML representations of Web service-based resources.
Service Modeling Language
WS-I 1.1 1.1 Oblix, OpenNetwork,
Working Group Draft W3C OASIS Ping Identity Corporation, Reactivity, WS-Transaction Resource Representation
Note Public Review Draft RSA Security, VeriSign and Westbridge
Technology ·Public Draft
Management (WS-TXM)
1.0 · Arjuna Technologies, Fujitsu, IONA,
SOAP Header Block (RRSHB)
W3C
Business Process Specifications
! SAML Token Profile is based on a non-proprietary ! Web Service Description Language 1.1 is an XML-based ! WS-Security: X.509 Certificate Token Profile describes ! WS-SecureConversation specifies how to manage and Recommendation
Web services specification, along with clarifications and Oracle and Sun Microsystems
language for describing Web services and how to access the use of the X.509 authentication framework with the authenticate message exchanges between parties including Committee Draft Business Process Execution Language for Web Services
amendments to that specification which promote them. It specifies the location of the service and the ! Resource Representation SOAP Header Block (RRSHB)
WS-Security: SOAP Message Security specification. security context exchange and establishing and deriving
interoperability. operations (or methods) the service exposes. session keys. ! WS-Transaction Management (WS-TXM) defines a core infrastructure complements MTOM by defining mechanisms for Web Service Choreography Description Language
service consisting of a Transaction Service for Web Services. describing and conveying non-XML resource representations

Transaction
Messaging
in a SOAP 1.2 message.

Reliability
Web Service Choreography Interface

Security
Conformance Claim WS-Choreography Model Overview
Attachment Mechanism (CCAM)
1.0 Business Process Management Language
WS-I
Final Specification Business Process Execution Language for Web Serv. 2.0

XML Process Definition Language


! Conformance Claim Attachment Mechanism (CCAM)
catalogues mechanisms that can be used to attach WS-I

Messaging Specifications SOAP


Profile Conformance Claims to Web services artefacts
(e.g., WSDL descriptions, UDDI registries).
Transaction Specifications

Messaging
Metadata
WS-Business Activity
Reliable Asynchronous " WS-Notification is a " WS-BrokeredNotification " WS-BaseNotification " WS-Eventing defines a " WS-Addressing – Core " SOAP Message
Messaging Profile (RAMP) family of related white defines the interface for standardizes the terminology, baseline set of operations provides transport-neutral SOAP Message Transmission WS-Atomic Transaction
1.0 WS-Notification papers and specifications WS-BrokeredNotification the NotificationBroker. WS-BaseNotification concepts, operations, WSDL
WS-Eventing that allow Web services to WS-Addressing – Core mechanisms to address SOAP Transmission Optimization
Optimization
WS-Coordination

Security
WS-I that define a standard A NotificationBroker is an and XML needed to express provide asynchronous Web services and messages. Mechanism
1.3 1.3 1.3 1.0 1.2
Working Draft OASIS
Web services approach to
notification using a topic- OASIS
intermediary, which, among
other things, allows OASIS
the basic roles involved in
Web services publish and
W3C notifications to interested
parties. W3C
This specification defines
XML elements to identify W3C Mechanism (MTOM) describes an
abstract feature for WS-Composite Application Framework
OASIS-Standard OASIS-Standard OASIS-Standard Public Draft Recommendation Recommendation 1.0 · W3C

Reliability
based publish/subscribe publication of messages subscribe for notification Web service endpoints and optimizing the
! Reliable Asynchronous Messaging Profile (RAMP) is a pattern. from entities that are not message exchange. to secure end-to-end Recommendation transmission and/or WS-Transaction Management
profile, in the fashion of the WS-I profiles, that enables, themselves service endpoint identification in wire format of a
among other things, basic B2B integration scenarios using providers. messages. SOAP message. WS-Context
Web services technologies.
" WS-Enumeration describes " WS-Topics defines three " WS-Addressing – WSDL " WS-Addressing – SOAP " SOAP is a lightweight,
WS-Enumeration a general SOAP-based
protocol for enumerating WS-Topics
topic expression dialects
that can be used as sub-
WS-Addressing – WSDL Binding defines how the
abstract properties defined
WS-Addressing – Binding provides transport-
neutral mechanisms to SOAP
XML-based protocol for
exchange of information
WS-Coordination Framework
Systinet, Microsoft, Sonic Software, BEA a sequence of XML
1.3
scription expressions in Binding in Web Services Addressing SOAP Binding address Web services and
1.1
in a decentralized,
Systems and
Presentation Specifications
elements that is suitable subscribe request messages 1.0 – Core are described using 1.0 messages. distributed environment.
for traversing logs, message OASIS and other parts of the WSDL. W3C
Computer Associates W3C W3C
queues, or other linear OASIS-Standard WS-Notification system. Note
Public Draft information models. Candidate Recommendation Recommendation

Reliab.

Secur.

Mess.
Web Services for Remote Portlets

Standards Bodies
The Organization for the Advancement of Structured Information
Standards (OASIS) is a not-for-profit, international consortium
that drives the development, convergence, and adoption of e-business standards. The
consortium produces more Web services standards than any other organization along with stan-
dards for security, e-business, and standardization efforts in the public sector and for applica-
tion-specific markets. Founded in 1993, OASIS has more than 4,000 participants representing
Version 3.0 · February 2007

over 600 organizations and individual members in 100 countries.

The World Wide Web Consortium (W3C) was created in October 1994 to lead the

XML Specifications
World Wide Web to its full potential by developing common protocols that promote
its evolution and ensure its interoperability. W3C has over 350 Member organiza-
tions from all over the world and has earned international recognition for its contributions to the
growth of the Web. W3C is designing the infrastructure, and defining the architecture and the core
technologies for Web services. In September 2000, W3C started the XML Protocol Activity to address
the need for an XML-based protocol for application-to-application messaging. In January 2002, the
Web Services Activity was launched, subsuming the XML Protocol Activity and extending its scope. " XML – Extensible Markup " XML – Extensible Markup " Namespaces in XML " XML Information Set is " XML Schema – XML " XML binary Optimized " Describing Media Content
Language is a pared-down Language is a pared-down provides a simple method an abstract data set to Schema Definition Language
XML binary Optimized Packaging (XOP) is an XML Describing Media Content of Binary Data in XML
The Web Services Interoperability Organization (WS-I) is an open industry
organization chartered to promote Web services interoperability across platforms, XML 1.1 version of SGML, designed
especially for Web
XML 1.0 version of SGML, designed
especially for Web
Namespaces in XML for qualifying element and
attribute names used in XML
XML Information Set provide a consistent set of
definitions for use in other
XML Schema is an XML language for
describing and constraining Packaging (XOP)
language for describing and
constraining the content of of Binary Data in XML
(DMCBDX) specifies how to
indicate the content-type
operating systems and programming languages. The organization’s diverse community of Web 1.1 documents. It allows one to 1.0 documents. It allows one to 1.1 documents by associating 1.0 specifications that need to 1.1 the content of XML XML documents. associated with binary
services leaders helps customers to develop interoperable Web services by providing guidance, W3C W3C W3C W3C W3C 1.0 (DMCBDX)
create own customized tags, create own customized tags, them with namespaces refer to the information documents. element content in an XML
recommended practices and supporting resources. Specifically, WS-I creates, promotes and
Recommendation enabling the definition, Recommendation enabling the definition, Recommendation identified by IRI references. Recommendation in a well-formed XML Working Draft W3C W3C document and to specify, in
supports generic protocols for the interoperable exchange of messages between Web services. Recommendation
transmission, validation, and transmission, validation, and document. Note XML Schema, the expected
The Internet Engineering Task Force (IETF) is a large open international
interpretation of data interpretation of data content-type(s) associated
between applications and between applications and with binary element
community of network designers, operators, vendors, and researchers
concerned with the evolution of the Internet architecture and the smooth between organizations. between organizations. content. innoQ Deutschland GmbH innoQ Schweiz GmbH
operation of the Internet.
Halskestraße 17 Gewerbestrasse 11
D-40880 Ratingen CH-6330 Cham
Phone +49 21 02 77 162 -100 Phone +41 41 743 01 11
info@innoq.com · www.innoq.com

Copyright innoQ 2008. All rights reserved.


http://www.innoq.com/resources/ws-standards-poster/
20
Why is SOA so
hard to define?

Copyright innoQ 2008. All rights reserved.

21
A Web service is a software system designed to
support interoperable machine-to-machine interaction
over a network. It has an interface described in a
machine-processable format (specifically WSDL). Other
systems interact with the Web service in a manner
prescribed by its description using SOAP messages,
typically conveyed using HTTP with an XML
serialization in conjunction with other Web-related
standards.
W3C Web Services Architecture WG
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/

Copyright innoQ 2008. All rights reserved.

22
“Service Oriented Architecture is a paradigm
for organizing and utilizing distributed capabilities that
may be under the control of different ownership
domains. It provides a uniform means to offer, discover,
interact with and use capabilities to produce desired
effects consistent with measurable preconditions and
expectations.”
OASIS SOA Reference Model
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

Copyright innoQ 2008. All rights reserved.

23
“An Economy is a paradigm
for organizing and utilizing distributed capabilities that
may be under the control of different ownership
domains. It provides a uniform means to offer, discover,
interact with and use capabilities to produce desired
effects consistent with measurable preconditions and
expectations.”
Nick Gall, VP, Gartner
http://tech.groups.yahoo.com/group/service-orientated-architecture/message/9065

Copyright innoQ 2008. All rights reserved.

24
What is REST?

Copyright innoQ 2008. All rights reserved.

25
3 definitions again

Copyright innoQ 2008. All rights reserved.

26
1

Copyright innoQ 2008. All rights reserved.

27
REST: An Architectural Style
One of a number of “architectural styles”
... described by Roy Fielding in his dissertation
... defined via a set of constraints that have to
be met
... architectural principles underlying HTTP,
defined a posteriori
... with the Web as one particular instance
See: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Copyright innoQ 2008. All rights reserved.

28
2

Copyright innoQ 2008. All rights reserved.

29
REST: The Web Used Correctly

A system or application architecture


... that uses HTTP, URI and other Web
standards “correctly”
... is “on” the Web, not tunneled through it
... also called “WOA”, “ROA”, “RESTful HTTP”

Copyright innoQ 2008. All rights reserved.

30
3

Copyright innoQ 2008. All rights reserved.

31
REST: XML without SOAP

Send plain XML (w/o a SOAP Envelope) via


HTTP
... violating the Web as much as WS-*
... preferably use GET to invoke methods
... or tunnel everything through POST
... commonly called “POX”

Copyright innoQ 2008. All rights reserved.

32
Only option 1 is the right one
(because Roy said so)

Copyright innoQ 2008. All rights reserved.

33
But we’ll go with option 2
(and equate “REST” with
“RESTful HTTP usage”)

Copyright innoQ 2008. All rights reserved.

34
and avoid option 3 like
the plague

Copyright innoQ 2008. All rights reserved.

35
REST Explained
in 5 Easy Steps

Copyright innoQ 2008. All rights reserved.

36
1. Give Every “Thing” an ID

http://example.com/customers/1234

http://example.com/orders/2007/10/776654

http://example.com/products/4554

http://example.com/processes/sal-increase-234

Copyright innoQ 2008. All rights reserved.

37
2. Link Things To Each Other

<order self=’http://example.com/orders/1234’>
<amount>23</amount>
<product ref=’http://example.com/products/4554’ />
<customer ref=’http://example.com/customers/1234’ />
</order>

Copyright innoQ 2008. All rights reserved.

38
3. Use Standard Methods
GET retrieve information, possibly cached

PUT Update or create with known ID

POST Create or append sub-resource

DELETE (Logically) remove

Copyright innoQ 2008. All rights reserved.

39
4. Allow for Multiple
“Representations”
GET /customers/1234
Host: example.com
Accept: application/vnd.mycompany.customer+xml

<customer>...</customer>

GET /customers/1234
Host: example.com
Accept: text/x-vcard

begin:vcard
...
end:vcard
Copyright innoQ 2008. All rights reserved.

40
5. Communicate Statelessly
GET /customers/1234
Host: example.com
Accept: application/vnd.mycompany.customer+xml

<customer><order ref=’./orders/46’</customer>

shutdown
update software
replace hardware
startup
GET /customers/1234/orders/46
Host: example.com
Accept: application/vnd.mycompany.order+xml

<order>...</order>
time Copyright innoQ 2008. All rights reserved.

41
Consequences

Copyright innoQ 2008. All rights reserved.

42
Copyright innoQ 2008. All rights reserved.

43
Cheating?

Copyright innoQ 2008. All rights reserved.

44
Maybe.

Copyright innoQ 2008. All rights reserved.

45
many

many very few


(one per service)

Copyright innoQ 2008. All rights reserved.

46
many

very few many


(fixed)

Copyright innoQ 2008. All rights reserved.

47
Designing a RESTful Application

Identify resources & design URIs


Select formats (or create new ones)
Identify method semantics
Select response codes

See: http://bitworking.org/news/How_to_create_a_REST_Protocol

Copyright innoQ 2008. All rights reserved.

48
What’s cool about
REST?

Copyright innoQ 2008. All rights reserved.

49
A very rough analogy
(in pseudocode)

Copyright innoQ 2008. All rights reserved.

50
generic
interface Resource {
     Resource(URI u) Any HTTP client
     Response get() (Firefox, IE, curl, wget)
     Response post(Request r)
     Response put(Request r) Any HTTP server
     Response delete()
} Caches
Proxies
Google,Yahoo!, MSN

class CustomerCollection : Resource { Anything that knows


     ... your app
     Response post(Request r) {
          id = createCustomer(r)
          return new Response(201, r)
}
     ...
}

specific
Copyright innoQ 2008. All rights reserved.

51
generic
Anything that
interface Resource { understands HTTP
...
}

class AtomFeed : Resource {


     AtomFeed get()
Any feed reader
post(Entry e)
...
Any AtomPub client
} Yahoo! Pipes

class CustomerCollection : AtomFeed { Anything that knows


     ... your app
}

specific
Copyright innoQ 2008. All rights reserved.

52
Some HTTP Features
Verbs (in order of popularity):
GET, POST
PUT, DELETE
HEAD, OPTIONS, TRACE
Standardized (& meaningful) response codes
Content negotiation
Redirection
Caching (incl. validation/expiry)
Compression
Chunking
Copyright innoQ 2008. All rights reserved.

53
RESTful HTTP Advantages

Universal support (programming languages, operating


systems, servers, ...)
Proven scalability
Real web integration for machine-2-machine
communication
Support for XML, but also other formats

Copyright innoQ 2008. All rights reserved.

54
REST and Web Services

Copyright innoQ 2008. All rights reserved.

55
Web Services Issues

Web Services are “Web” in name only


WS-* tends to ignore the web
Abstractions leak, anyway
Protocol independence is a bug, not a feature

Copyright innoQ 2008. All rights reserved.

56
Web Services
OrderManagementService

+ getOrders()
A separate interface (façade)
+ submitOrder() for each purpose
+ getOrderDetails()
+ getOrdersForCustomers()
+ updateOrder() As known CORBA, DCOM,
+ addOrderItem()
+ cancelOrder() RMI/EJB
+ cancelAllOrders()
Often used for SOA
(“CORBA w/ angle
CustomerManagementService
brackets)
+ getCustomers()
+ addCustomer()
+ getCustomerDetails() Application-specific protocol
+ updateCustomer()
+ deleteCustomer()
+ deleteAllCustomers()

Copyright innoQ 2008. All rights reserved.

57
Contribution to the Net’s Value

2 URLs
http://example.com/customerservice
http://example.com/orderservice
1 method
POST

Copyright innoQ 2008. All rights reserved.

58
REST Approach
A single generic (uniform)
/orders
GET - list all orders
PUT - unused
POST - add a new order
DELETE - cancel all orders interface for everything
/orders/{id}
GET - get order details
PUT - update order
POST - add item
Generic verbs mapped to
DELETE - cancel order
resource semantics
«interface» /customers
Resource
GET
PUT
GET - list all customers
PUT - unused
POST - add new customer
A standard application
protocol (e.g. HTTP)
POST
DELETE - delete all customers
DELETE

/customers/{id}
GET - get customer details
PUT - update customer
POST - unused
DELETE - delete customer

/customers/{id}/orders
GET - get all orders for customer
PUT - unused
POST - add order
DELETE - cancel all customer orders

Copyright innoQ 2008. All rights reserved.

59
Contribution to the Net’s Value

Millions of URLs
every customer
every order
4-6 supported methods per resource
GET, PUT, POST, DELETE, OPTIONS, HEAD
Cacheable, addressable, linkable, ...
Copyright innoQ 2008. All rights reserved.

60
REST for
vs. SOA

Business SOA as an approach to business/IT alignment

Architecture Technical SOA REST

Technology SOAP, WSDL, WS-* (RESTful) HTTP, URI, ...

Copyright innoQ 2008. All rights reserved.

61
REST as an
alternative way to
achieve SOA goals

Copyright innoQ 2008. All rights reserved.

62
Why You Should Care

Copyright innoQ 2008. All rights reserved.

63
WS-* Roots

The Enterprise
RPC, COM, CORBA, RMI, EJB
Transaction Systems
Controlled Environment
Top-down Approach

Copyright innoQ 2008. All rights reserved.

64
REST Roots

The Internet
Text formats
Wire Standards
FTP, POP, SMTP
Bottom-up Approach

Copyright innoQ 2008. All rights reserved.

65
Internet vs. Enterprise

Copyright innoQ 2008. All rights reserved.

66
What’s the difference
between the Internet
and a typical
enterprise?

Copyright innoQ 2008. All rights reserved.

67
Internet vs. Enterprise
One is a gigantic, uncontrollable anarchy of
heterogeneous systems with varying quality
that evolve independently and constantly get
connected in new and unexpected ways.

The other is a worldwide, publicly accessible


series of interconnected computer networks
that transmit data by packet switching using
the standard Internet Protocol (IP).
Copyright innoQ 2008. All rights reserved.

68
REST Support

Copyright innoQ 2008. All rights reserved.

69
Everybody HTTP Servers, Clients, Proxies, Libraries, ...

DHH & The Rails Community Ruby on Rails


Google Base
GData
Calendar
Document Lists
Blogger
Notebook
Picasa
Amazon Simple Storage Service (S3)
Queue Service
Flexible Payment
Search
Sun JSR 311
Jersey

IBM Abdera
Project Zero

Microsoft Astoria
WCF

Copyright innoQ 2008. All rights reserved.

70
Advanced Stuff

Copyright innoQ 2008. All rights reserved.

71
Description
What’s the WSDL equivalent in REST?

Copyright innoQ 2008. All rights reserved.

72
There is none ...

XSD (95% of WSDL) is available to you, anyway


Of the remaining 5%, 90% is just silly
Why would you want to describe the uniform
interface over and over again?

Copyright innoQ 2008. All rights reserved.

73
... unless you insist

WADL (Web Application Description Language)


https://wadl.dev.java.net/
Use URI Templates to define resource behavior

Copyright innoQ 2008. All rights reserved.

74
WADL Example
<resources base="http://api.search.yahoo.com/NewsSearchService/V1/">
<resource path="newsSearch">
<method name="GET" id="search">
<request>
<param name="appid" type="xsd:string" style="query" required="true"/>
<param name="query" type="xsd:string" style="query" required="true"/>
<param name="type" style="query" default="all">
<option value="all"/>
<option value="any"/>
<option value="phrase"/>
</param>
<param name="results" style="query" type="xsd:int" default="10"/>
<param name="start" style="query" type="xsd:int" default="1"/>
<param name="sort" style="query" default="rank">
<option value="rank"/>
<option value="date"/>
</param>
<param name="language" style="query" type="xsd:string"/>
</request>
<response>
<representation mediaType="application/xml" element="yn:ResultSet"/>
<fault status="400" mediaType="application/xml" element="ya:Error"/>
</response>
</method>
</resource>
</resources>
Copyright innoQ 2008. All rights reserved.

75
What You Should Do
(in my very humble opinion)

Copyright innoQ 2008. All rights reserved.

76
Be skeptical of WS-*
Learn more about REST
Learn to love the URI

Appreciate the Web

Copyright innoQ 2008. All rights reserved.

77
If You Want to Know More

Copyright innoQ 2008. All rights reserved.

78
http://www.innoq.com/resources/REST

Copyright innoQ 2008. All rights reserved.

79
http://www.oreilly.com/catalog/9780596529260/
Copyright innoQ 2008. All rights reserved.

80
http://www.infoq.com

Copyright innoQ 2008. All rights reserved.

81
Final Specification

These company, organisation, brand and product names


Copyright innoQ Deutschland GmbH. All Rights Reser
This poster is not to be reproduced or tr
Basic Security Profile
1.0
WS-I
Board Approval Draft

REL Token Profile


1.0
WS-I
Working Group Draft

SAML Token Profile


1.0

©
WS-I
Working Group Draft

Thank you!
Conformance Claim
Attachment Mechanism
(CCAM)
1.0
WS-I
Final Specification

Reliable Asynchronous
Messaging Profile (RAMP)
1.0
WS-I
Working Draft

Version 3.0* · February 2007


Stefan Tilkov
http://www.innoq.com/blog/st/
stefan.tilkov@innoq.com innoQ Deutschland GmbH innoQ Schweiz GmbH
Halskestraße 17 Gewerbestrasse 11
D-40880 Ratingen CH-6330 Cham
Phone +49 21 02 77 162-100 Phone +41 41 743 0111
info@innoq.com · www.innoq.com

Copyright innoQ 2008. All rights reserved.

82
Photo Credit

http://www.flickr.com/photos/toddography/462611643/
http://www.flickr.com/photos/raveller/159146501/
http://en.wikipedia.org/wiki/Image:Sangreal.jpg

Copyright innoQ 2008. All rights reserved.

83

You might also like