RestFul Services. Part 2

Содержание

Слайд 2

Agenda What is Rest? Conceptual overview Restful Web services SOAP vs

Agenda

What is Rest? Conceptual overview
Restful Web services
SOAP vs REST
High-level example: hotel

booking
Technologies
Using HTTP to build REST Applications
Слайд 3

Слайд 4

Слайд 5

Conceptual Overview Representational State Transfer (REST) Representational State Transfer (REST) A

Conceptual Overview Representational State Transfer (REST)

Representational State Transfer (REST)
A style of software

architecture for distributed hypermedia systems such as the World Wide Web.
REST is basically client/server architectural style
Requests and responses are built around the transfer of "representations" of "resources".
REST is centered around two basic principles:
Resources as URLs. A resource is something like a "business entity" in modelling lingo. It's an entity you wish to expose as part of an API. Almost always, the entity is a noun, e.g. a person, a car, or a football match. Each resource is represented as a unique URL.
Operations as HTTP methods. REST leverages the existing HTTP methods, particularly GET, POST, PUT, and DELETE.
Слайд 6

RESTful Web Service definition A RESTful Web service is: A set

RESTful Web Service definition

A RESTful Web service is:
A set of Web

resources.
Interlinked.
Data-centric, not functionality-centric.
Machine-oriented.
Like Web applications, but for machines.
Like SOAP, but with more Web resources.
Слайд 7

SOAP collection service collection entry entry entry listEntries() addEntry() getEntry() deleteEntry()


SOAP

collection
service

collection

entry

entry

entry

listEntries()
addEntry()
getEntry()
deleteEntry()
updateEntry()

listEntries()
addEntry()
getEntry()
deleteEntry()
updateEntry()

RESTful

SOAP vs REST: A quick comparison

Слайд 8

A SOAP service has a single endpoint that handles all the

A SOAP service has a single endpoint that handles all the

operations – therefore it has to have an application-specific interface.
A RESTful service has a number of resources (the collection, each entry), so the operations can be distributed onto the resources and mapped to a small uniform set of operations.

SOAP vs REST: A quick comparison

Слайд 9

High-level example: hotel booking

High-level example: hotel booking

Слайд 10

Hotel booking workflow Retrieve service description Submit search criteria according to

Hotel booking workflow
Retrieve service description
Submit search criteria according to description
Retrieve linked

details of interesting hotels
Submit payment details according to selected rate description
Retrieve confirmation of booking
2b. Retrieve list of user's bookings

High-level example: hotel booking

Слайд 11

search(date, city) ? list of hotels & rates getHotelDetails(hotel) ? hotel

search(date, city)
? list of hotels & rates
getHotelDetails(hotel)
? hotel details
reserve(rate, creditCard)
? confirmationID
getConfirmationDetails(confID)
?

confirmation details
listMyBookings()
? list of confirmationIDs

nouns vs. verbs

hypermedia -> operations

High-level example: hotel booking

Слайд 12

RestFull Services. Technologies Todays’s set of technologies, protocols and languages used

RestFull Services. Technologies

Todays’s set of technologies, protocols and languages used to

apply RESTful paradigm:
HTTP as the basis
XML and JSON for data exchange
AJAX for client-side programming (e.g. browser)
Слайд 13

Using HTTP to build REST Applications The REST Recipe: Find all

Using HTTP to build REST Applications

The REST Recipe:
Find all the nouns,
Define

the formats,
Pick the operations,
Highlight exceptional status codes.
Слайд 14

Using HTTP to build REST Applications Find all the nouns: Everything

Using HTTP to build REST Applications

Find all the nouns:
Everything in a

RESTful system is a resource – a noun.
Every resource has a URI,
URIs should be descriptive:
http://example.com/expenses;pending
Not a REST principle, but a good idea!
URIs should be opaque:
automated (non-human) clients should not infer meaning from a URI.
Слайд 15

Using HTTP to build REST Applications Find all the nouns: Use

Using HTTP to build REST Applications

Find all the nouns:
Use path variables

to encode hierarchy:
/expenses/123
Use other punctuation to avoid implying hierarchy:
/expenses/Q107;Q307
/expenses/lacey,peter
Use query variables to imply inputs into an algorithm:
/search?approved=false
Caches tend to (wrongly) ignore URIs with query variables!
URI space is infinite (but URI length is not ~ 4K).
Слайд 16

Using HTTP to build REST Applications

Using HTTP to build REST Applications

Слайд 17

Using HTTP to build REST Applications Define the formats: Neither HTTP

Using HTTP to build REST Applications

Define the formats:
Neither HTTP nor REST

mandate a single representation for data.
A resource may have multiple representations:
XML, JSON, binary (e.g., jpeg), name/value pairs
Schema languages are not required (if even possible).
Representations should be well-known media types (MIME types).
Try and use “up-stack” media types:
Makes your resources maximally accessible,
XHTML or Atom instead of vanilla XML.
Слайд 18

Using HTTP to build REST Applications Pick the operations: HTTP has

Using HTTP to build REST Applications

Pick the operations:
HTTP has a constrained

user interface (set of verbs/operations/methods):
GET,
POST,
PUT,
DELETE,
HEAD,
OPTIONS (not widely supported),
TRACE (not significant),
CONNECT (not significant).
All of our resources will support GET!
Слайд 19

Using HTTP to build REST Applications GET returns a representation of

Using HTTP to build REST Applications

GET returns a representation of the

current state of a resource.
GET is “safe”:
Does not change resource state,
May trivially change server side state, e.g. log files,
GET is “idempotent”:
Multiple requests are the same as a single request,
Might be impacted by concurrent operations.
NEVER violate these rule.
Слайд 20

Using HTTP to build REST Applications Highlight exceptional status codes: HTTP

Using HTTP to build REST Applications

Highlight exceptional status codes:
HTTP has more

response codes than 200 and 404 – learn them:
Information: 1xx, Success 2xx, Redirection 3xx, Client Error 4xx, Server Error 5xx;
For GETs we will need:
200 OK,
204 No Content,
404 Not Found,
We’ll need more later.