History

• Origin of the Web: 1989-1991
• HTML forms
• Very early: interaction with programs on the Web

Services on the Web

• Large diversity
• Focus recently changed from human to machines
• Different philosophies about architecting services have emerged
• Similarities; XML is used as the document format
• Two main ones:
  • One, following closely the architecture of the Web
  • Another one, message-oriented, with machine processable descriptions, defining a set of very extensible technologies
• Opposition between those approaches

The Web architecture: introducing resources

• Distributed hypertext environment
• Things that one wants to talk about is a resource; e.g., the home page of W3C
• A resource is indentified by a Uniform Resource Identifier, a URI; e.g., http://www.w3.org/
• In today's internationalized world, identifiers are IRIs; e.g. http://ヒキワリ.ナットウ.ニホン.example/

The Web architecture: interacting with resources

• One can retrieve a representation of a resource: e.g., an XHTML 1.0 Strict document, with a title element whose content is World Wide Web Consortium, etc.

  

• Retrieving resources (HTTP GET) has interesting properties:
  • No side effects: only information retrieval; safe interaction
  • Cacheable
  • Bookmarkable
  • One of the core properties of the Web

More interactions with resources

• Not only a readable space
• One can also create, update, delete resources, with other HTTP methods:
  • POST: process message
  • PUT: update representation
  • DELETE: delete resource

What is REST?

• REST stands for Representational State Transfer
• Architectural style for distributed hypermedia systems, introduced by Roy Fielding
• Uniform interface for resources
• Stateless communication
• Cacheability

Introducing REST services

• Services on the Web, following REST philosophy
• Using HTTP uniform interface: GET, POST, PUT, DELETE
• Format of the representation: XML
• Example:
  • Syndication using RSS
  • MusicBrainz API
  • AJAX (Asynchronous JavaScript and XML)'s XMLHttpRequest
• Have become synonymous of non-SOAP services

What are Web services?

• Different definitions
• General one: services on the Web
• REST services are part of the definition
• Term usually used to specify a particular way of doing services on the Web, i.e. SOAP-based Web services

SOAP-based Web services

A definition:

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.

Technologies involved in SOAP-based Web services

• SOAP
• WSDL
• Plenty of extensions built on top of those technologies:
  • Addressing
  • Asynchrony
  • Reliability
  • Integrity
  • Authenticity
  • Etc.
• Integration technology

Opposition of REST and Web services

• Why? SOAP is a document format
• Issue comes from example 1 in the SOAP 1.1 specification:

  POST /StockQuote HTTP/1.1
  Host: www.stockquoteserver.com
  Content-Type: text/xml; charset="utf-8"
  Content-Length: nnnn
  SOAPAction: "Some-URI"
  
  <SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
     <SOAP-ENV:Body>
         <m:GetLastTradePrice xmlns:m="Some-URI">
             <symbol>DIS</symbol>
         </m:GetLastTradePrice>
     </SOAP-ENV:Body>
  </SOAP-ENV:Envelope>

• Goes against the Web architecture: simple information retrieval is done with GET

  http://stockquoteserver.example/query?symbol=DIS

• HTTP tunnelling with HTTP POST

Criticisms made by opposed communities

• Against Web services:
  • Web services are reinventing the Web through HTTP POST
  • Web services are too complex compared to REST services
  • Losing benefits of the Web
• Against REST services:
  • Foolish to want to model everything as GET, POST, PUT and DELETE operations
  • How do you deal with things like transactions, reliability, etc.?

(non-exhaustive lists)

Sounds familiar?

Another look at the comparison

• Web services are very ambitious
  • A summary of SOAP: extensibility and processing models
  • Extensions designed: asynchrony, reliability, integrity, confidentiality, etc.
  • Protocol independent
  • Machine-processable description of services
  • Machine-processable description of composition of services
• Simplicity of REST services is mainly at the technological level
  • Not all challenges tackled (integrity, reliability, etc.)
  • More is up to the developer
  • Need to model system as resources
  • HTTP Extension Framework was addressing similar issues

Finding a non-adversarial view

• Each have their advantages and their drawbacks
• Web services are not so antagonistic to REST:

1. SOAP-based Web services can be RESTful: there is a vi-mode for Web services
2. Web services technologies can be useful in the context of non-SOAP-based REST services

A look at the Web services stack

Doing SOAP-based Web services in RESTful ways

1. SOAP-based Web services can be RESTful: there is a vi-mode for Web services
2. Web services technologies can be useful in the context of non-SOAP-based REST services

SOAP 1.2 in a nutshell

• XML-based messaging framework
• Processing model
• Extensibility model
• SOAP messages:
  • One-way messages
  • XML documents described with an XML Infoset
  • Transmitted by an underlying protocol from one node to another: typically HTTP

Using SOAP 1.2 in RESTful ways

• SOAP 1.2 is not restricted to use over HTTP POST
• SOAP 1.2 HTTP binding does support HTTP GET
• Allows to leverage URI addressibility, Web caching, etc.

• Response can use SOAP extensions, e.g. encryption of part of the message
• One can design a system made of resources, and use SOAP with HTTP GET and POST where appropriate

Weather SOAP-based Web service designed in a non RESTful way

Non RESTful service details

• One endpoint: http://weather.example/endpoint
• Messages accepted at this endpoint (SOAP in HTTP POST in, SOAP out):
  • GetWeather: get the current weather at a city
  • AddCity: add a city to the system
  • SetWeather: set weather information for a city
  • DelCity: delete a city from the system
• Example of GetWeather:

  POST /endpoint HTTP/1.1
  Host: weather.example
  Content-Type: application/soap+xml
  Content-Length: 251
  
  <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
    <env:Body>
      <w:GetWeather xmlns:w="http://weather.example/">
        <w:city>Växjö</w:city>
        <w:country>Sweden</w:country>
      </w:GetWeather>
     </env:Body>
  </env:Envelope>

• Bad example from a Web architecture point of view:

  A simple "get" operation should be done with HTTP GET

Same SOAP-based Web service designed in a RESTful way

RESTful service details

• Each city has a resource associated with it: http://weather.example/country/city
• Operations:
  • GET http://weather.example/country/city: get the current weather at a city
    SOAP out
  • POST http://weather.example/country/city: set weather information for a city
    SOAP in, SOAP out
  • DELETE http://weather.example/country/city: delete a city from the system
  • POST http://weather.example/addCity: add a city to the system
    SOAP in, SOAP out
• Using SOAP for the message format: one can still use security extensions, authenticity checks using certificates, etc.
• Example of a GET:

  GET /Sweden/V%C3%A4xj%C3%B6 HTTP/1.1
  Host: weather.example
  Accept: application/soap+xml

Web services technologies for REST services

1. SOAP-based Web services can be RESTful: there is a vi-mode for Web services
2. Web services technologies can be useful in the context of non-SOAP-based REST services

Dealing with hyperlinks in REST services

<weather …>
  <temperature>13</temperature>
  <sky>sunny</sky>
  <img xlink:href="http://weather.example/cam/Sweden/V%C3%A4xj%C3%B6?time=0800" />
</weather>

• Link to an image
• Potential issues faced:
  • Limited Web access
  • Latency
  • Etc.
• Including it in the document: challenges

SOAP Message Transmission Optimization Mechanism

Using RRSHB for hyperlinks

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:rep='http://www.w3.org/2004/08/representation'
    xmlns:xmlmime='http://www.w3.org/2005/05/xmlmime'>
 <soap:Header>
  <rep:Representation 
       resource="http://weather.example/cam/Sweden/V%C3%A4xj%C3%B6?time=0800">
   <rep:Data
   xmlmime:contentType='image/jpeg'>/aWKKapGGyQ=</rep:Data>
  </rep:Representation>
 </soap:Header>
 <soap:Body>
  <weather …>
   <temperature>13</temperature>
   <sky>sunny</sky>
   <img xlink:href="http://weather.example/cam/Sweden/V%C3%A4xj%C3%B6/0800" />
  </weather>
 </soap:Body>
</soap:Envelope>

Then optimize with MTOM

Introducing WSDL 2.0

• Description language for Web services

  

• Message format
• Protocol used
• Location of a service

WSDL 2.0 to describe HTTP services

• WSDL 2.0 is tailored for SOAP-based Web services
• However, HTTP binding in WSDL 2.0 allows for good description of HTTP services

<binding name="HttpBinding" interface="m:GetTemperature"
         type="http://www.w3.org/2005/08/wsdl/http">
  <operation ref="m:location" whttp:method="GET"
             whttp:location="{country}/{city}"/>
</binding>

allows for an HTTP GET on http://weather.example/Sweden/V%C3%A4xj%C3%B6:

HTTP/1.1 200 Here's the temperature for you
Content-Type: application/xml
…

<weather xmlns="…">
  <temperature>23</temperature>
</weather>

WSDL 2.0 HTTP binding

• All HTTP methods are supported

<interface name="Maintenance">
  <operation name="weather">
    <input messageLabel="In" element="s:weather"/>
    <output messageLabel="Out" element="#none"/>
  </operation>
  <operation name="DelCity">
    <input messageLabel="In" element="s:City"/>
    <output messageLabel="Out" element="#none"/>
  </operation>
</interface>

<binding name="HttpBindng" interface="m:Maintenance"         
         type="http://www.w3.org/2005/08/wsdl/http">
  <operation ref="m:weather" whttp:method="PUT"
             whttp:location="{country}/{city}"/>
  <operation ref="m:DelCity" whttp:method="DELETE"
             whttp:location="{country}/{city}"/>
</binding>

<service>
  <endpoint name="AdminEndpoint" binding="m:HttpBinding"
            whttp:authenticationType="digest"
            whttp:realm="admin"
            address="http://ws.accurateweather.example/"/>
</service>

Messages from example REST service: PUT

HTTP PUT to upload new data

PUT /Sweden/V%C3%A4xj%C3%B6 HTTP/1.1
Host: ws.accurateweather.example
Authorization: Digest username="hugo",
        realm="admin",
        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
        uri="/Sweden/V%C3%A4xj%C3%B6",
        …
Content-Type: application/xml
…

<weather xmlns="…">
  <temperature>23</temperature>
</weather>

with a response:

HTTP/1.1 204 Resource updated

Messages from example REST service: DELETE

HTTP DELETE to erase a city

DELETE /Sweden/V%C3%A4xj%C3%B6 HTTP/1.1
Host: ws.accurateweather.example
Authorization: Digest username="hugo",
        realm="admin",
        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
        uri="/Sweden/V%C3%A4xj%C3%B6",
        …
    

with a response:

HTTP/1.1 204 City deleted

WS-CDL 1.0

• Web Services Choreography Description Language
• Multi-party contract that describes from a global view point the external observable behavior
• Describes the exchange of messages

Example of a WS-CDL description

• Can describe REST services described
• WSDL may be used for interface descriptions
• WSDL may describe a REST service
• A REST-specific description language may be used

Upcoming areas of common interest

• Work on XML Schema Patterns for Databinding
• Semantics in Web services descriptions

Reconciling the communities

• A set of technologies, that can be used with two design philosophies
• Benefits to both approaches
• Large overlap in their capabilities
• Not expecting to have the debate go away

  After all, the editor war has been going on for decades

• Useful for both communities to look at the benefits of the other camp

References

• W3C Web Services Activity page: http://www.w3.org/2002/ws/
• This talk linked from http://www.w3.org/Talks/