Beruflich Dokumente
Kultur Dokumente
• Stateless
– No client state is stored on server
– Each request contains enough context to process
the message
REST Constraints
• Cacheable
– Clients can cache responses
– Responses shall define themselves as cacheable or
not
• Uniform Interface
– Defines the interface between client & server
– Simplifies & Decouples the architecture
– HTTP Verbs, URI’s, Response (Status & body)
REST Constraints (Contd.)
• Layered System
– Client can’t assume direct connection to the end
server
– Intermediate layers may exist in-between
• Code on Demand
– Server can temporarily extend client by
transferring logic to it. Client executes that logic.
– Only OPTIONAL constraint
HTTP
• is a TCP/IP based application layer protocol that
allows web-based applications to communicate &
exchange data.
• Stateless ( like REST )
• Connectionless
• Can deliver any data
• 3 sections
– Start line
– Header
– Body
HTTP Verbs
Safe Idempotent Cacheable
GET
PUT
DELETE
POST
Request:
POST /doctors/mjones HTTP/1.1
[various other headers]
<openSlotRequest date = "2010-01-04"/>
Maturity Level 1 : Example (Contd.)
The reply carries the same basic information, but each slot is
now a resource that can be addressed individually.
Response:
HTTP/1.1 200 OK
[various headers]
<openSlotList>
<slot id = "1234" doctor = "mjones" start = "1400"
end = "1450"/>
<slot id = "5678" doctor = "mjones" start = "1600"
end = "1650"/>
</openSlotList>
Maturity Level 1 : Example (Contd.)
With specific resources booking an appointment
means posting to a particular slot.
Request:
POST /slots/1234 HTTP/1.1
[various other headers]
<appointmentRequest>
<patient id = "jsmith"/>
</appointmentRequest>
Maturity Level 1 : Example (Contd.)
Response: Success
HTTP/1.1 200 OK
[various headers]
<appointment>
<slot id = "1234" doctor = "mjones"
start = "1400" end = "1450"/>
<patient id = "jsmith"/>
</appointment>
Maturity Level 2:
HTTP Verbs & Status Codes
• When your API uses HTTP verbs, it might be level 2.
• Many URI’s, each supporting multiple HTTP methods.
• Rules:
– Use appropriate method for the purpose intended.
– Don't use a single POST method for all.
– Make use of GET when you are requesting resources.
– Use the DELETE method when you want to delete a
resource.
– Also, use the response codes of your application protocol.
Don't use 200 (OK) code when something went wrong for
instance.
Maturity Level 2 : Example
Maturity Level 2 : Example (Contd.)
• Now we will use GET method to retrieve list of
slots:
Request:
GET /doctors/mjones/slots?date=20100104&status=open
HTTP/1.1
Host: royalhope.nhs.uk
Maturity Level 2 : Example (Contd.)
The reply is the same as it would have been with
the POST of maturity Level 1
Response:
HTTP/1.1 200 OK
[various headers]
<openSlotList>
<slot id = "1234" doctor = "mjones"
start = "1400" end = "1450"/>
<slot id = "5678" doctor = "mjones"
start = "1600" end = "1650"/>
</openSlotList>
Maturity Level 2 : Example (Contd.)
To book an appointment we need an HTTP verb
that does change state, a POST or a PUT.
I'll use the same POST that I did earlier.
Request:
POST /slots/1234 HTTP/1.1
[various other headers]
<appointmentRequest>
<patient id = "jsmith"/>
</appointmentRequest>
Maturity Level 2 : Example (Contd.)
• Response : Success
HTTP/1.1 201 Created
Location: slots/1234/appointment
[various headers]
<appointment>
<slot id = "1234" doctor = "mjones"
start = "1400" end = "1450"/>
<patient id = "jsmith"/>
</appointment>
Maturity Level 2 : Example (Contd.)
• Response: Some error
Request
GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk
Maturity Level 3 : Example (Contd.)
But the response has a new element:
HTTP/1.1 200 OK
[various headers]
<openSlotList>
<slot id = "1234" doctor = "mjones" start = "1400" end = "1450">
<link rel = "/linkrels/slot/book" uri = "/slots/1234"/>
</slot>
<slot id = "5678" doctor = "mjones" start = "1600" end = "1650">
<link rel = "/linkrels/slot/book" uri = "/slots/5678"/>
</slot>
</openSlotList>
Each slot now has a link element which contains a URI to tell us how to
book an appointment.
Maturity Level 3 : Example (Contd.)
The POST would again copy that of level 2
Request:
POST /slots/1234 HTTP/1.1
[various other headers]
<appointmentRequest>
<patient id = "jsmith"/>
</appointmentRequest>
Maturity Level 3 : Example (Contd.)
And the response contains a number of hypermedia controls for different
things to do next.
HTTP/1.1 201 Created
Location: http://royalhope.nhs.uk/slots/1234/appointment
[various headers]
<appointment>
<slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
<patient id = "jsmith"/>
<link rel = "/linkrels/appointment/cancel" uri = "/slots/1234/appointment"/>
<link rel = "/linkrels/appointment/addTest" uri = "/slots/1234/appointment/tests"/>
<link rel = "self" uri = "/slots/1234/appointment"/>
<link rel = "/linkrels/appointment/changeTime" uri =
"/doctors/mjones/slots?date=20100104@status=open"/>
<link rel = "/linkrels/appointment/updateContactInfo" uri =
"/patients/jsmith/contactInfo"/>
<link rel = "/linkrels/help" uri = "/help/appointment"/>
</appointment>
REST Maturity Levels
Summary
• Level 0:
– Single service endpoint for all requests
• Level 1:
– API can distinguish between different resources
– tackles the question of handling complexity by
using divide and conquer, breaking a large service
endpoint down into multiple resources.
Summary
• Level 2:
– API uses appropriate HTTP verbs & status codes
– introduces a standard set of verbs so that we
handle similar situations in the same way,
removing unnecessary variation.
• Level 3:
– Returns the URI of the resource, that can be used
for the next operation.
– Introduces discoverability, providing a way of
making a protocol more self-documenting.
THANK YOU