REST

fortnecessityusefulΛογισμικό & κατασκευή λογ/κού

14 Δεκ 2013 (πριν από 3 χρόνια και 9 μήνες)

99 εμφανίσεις


Programming Web Services:

RPC via SOAP and REST

2

Service
-
Oriented
Computing

RPC via SOAP


A Web service is typically invoked by sending a SOAP
message to it and receiving a response in the form of
another SOAP message


The SOAP messages and their contents are not
themselves stored anywhere on the Web or
accessible


Invoking a Web service is like a remote procedure
call (RPC) or a database query


Hiding content inside SOAP messages means Web
machinery for caching and security checks cannot be
used

3

Service
-
Oriented
Computing

Representational State Transfer


REST is an architectural style for networked systems
that constrains the connector semantics (not the
component semantics)


The Web is a network of hyperlinked
resources
,
which are things identified by a
Uniform
Resource
Identifier
(URI)


A URI can be either a
Uniform Resource Name

(URN) or a
Uniform Resource Locator
(URL)


A Web application works as a state machine


A client selecting a link is causing a state transition,
resulting in receiving the next page (next state) of
the application


A
RESTful

service is a collection of resources
identified by
baseURI
/ID, e.g., hotel rooms accessed
by http://rest.com/resources/hotel/123

4

Service
-
Oriented
Computing

Characteristics of REST


Client
-
Server


Statelessness: requests cannot take advantage of
stored contexts on a server


Great for load balancing


Caching: responses can be labeled as cacheable


Uniform interface


URIs, hypermedia


Layered components


Focus on resources as opposed to methods:


Read, construct, update a resource representation using the
http verbs GET, POST, PUT, and DELETE


Well
-
suited to hypermedia applications

HTTP Verbs


Popular verbs


Get: query or read a resource (idempotent)


Post: create or update a resource


Put: creates a new resource (idempotent)


Delete: removes a resource


Idempotent operations: no side effects


Multiple executions = one execution


Challenge: the specification imposes requirements
but with no way to judge compliance

Especially, can use Get and Post instead of much of
SOAP

5

Service
-
Oriented
Computing

Web Application Description Language
(WADL)

A WADL document has the following elements:


Application


overall description, with location of
WADL document and other namespaces


Grammars


definitions of XML structures
exchanged


Resources


a container for a Resource, which is
ID’d

by a URI and can have associated Methods


Methods


descriptions of the inputs/outputs
applied to HTTP actions on a Resource, often in
the form of a request
subelement

and a response
subelement

6

Service
-
Oriented Computing

WADL Example

7

Service
-
Oriented Computing

Flickr
RESTful

Documentation

8

Service
-
Oriented Computing

9

Service
-
Oriented Computing

JSON, and in XML

JSON as Text

10

Service
-
Oriented Computing

JSON in XML

11

Service
-
Oriented Computing

RESTful

Atom Publishing Protocol

12

Service
-
Oriented Computing

13

Service
-
Oriented
Computing

Software for Open Environments


Tempting to simply lift current database
and programming techniques for open
environments


Popular pitfall encouraged by the tools:


Think of objects (get and set methods)


Invoke them as before even though they
are Web services


Poor performance


Tight coupling

14

Service
-
Oriented
Computing

Suppose you want to sell cameras over the
Web, debit a credit card, and guarantee
next
-
day delivery


Your application must


update sales database


debit the credit card


send an order to the shipping department


receive an OK from the shipping department for
next
-
day delivery


update an inventory database


Problems: Some steps complete but not all

Simple B2C Web Service Example

15

Service
-
Oriented
Computing

“Traditional” B2C Problems


What if the order is shipped, but the debit
fails?


What if the debit succeeds, but the order was
never entered or shipped?

16

Service
-
Oriented
Computing

Database Approach

A traditional database approach works only for a closed
environment:


Transaction processing (TP) monitors (such as IBM’s
CICS, Transarc’s Encina, BEA System’s Tuxedo) can
ensure that all or none of the steps are completed, and
that systems eventually reach a consistent state


But what if the user’s modem is disconnected right after
he clicks on OK? Did the order succeed? What if the line
went dead before the acknowledgement arrives? Will the
user order again?


The TP monitor cannot get the user into a consistent state!

17

Service
-
Oriented
Computing

Approach for Open Environment


Server application could send email about credit
problems, or detect duplicate transactions


Downloaded applet could synchronize with server
after broken connection was restored, and recover
transaction; applet could communicate using http, or
directly with server objects via CORBA/IIOP or RMI


If there are too many orders to process
synchronously, they could be put in a message
queue, managed by a Message Oriented Middleware
server (which guarantees message delivery or failure
notification), and customers would be notified by
email when the transaction is complete

The server behaves like an agent!

18

Service
-
Oriented
Computing

Requirements


Cross
-
enterprise processes


Exception handling


Conversations and long
-
lived
transactions


Contracts among parties involved

REST Principles

19

Service
-
Oriented Computing

SOAP RPC vs. REST

Sample SOAP code to retrieve an employee’s benefits:

<
SOAP
-
ENV:Envelope

xmlns:SOAP


ENV
="
http://schemas.xmlsoap.org/soap/envelope/
">


<
SOAP
-
ENV:Header
>

some
data here...
</
SOAP
-
ENV:Header
>


<
SOAP
-
ENV:Body
>


<
GetBenefits
>


<
user>123
-
45
-
6789</user>


<
type>
full_time_employee
</type>


</
GetBenefits
>


</
SOAP
-
ENV:Body
>

</
SOAP
-
ENV:Envelope
>


REST equivalent:

http
://humanresources.com/benefits?user=<USER_SSID>
&type=full_time_employee

20

Service
-
Oriented Computing

21

Service
-
Oriented
Computing

Summary


Tools help with low
-
level details


Agreeing on standards is more important than the
standards themselves


Should conceptualize interactions in a manner
compatible with the Web architecture


Can simplify from SOAP in many cases


The above is a small point anyway


Bigger challenges are in ensuring larger
-
scale
interactions, ensuring integrity, handling
exceptions, …


Sophisticated programming models are emerging