The document describes Representational State Transfer (REST) architectural constraints and how they promote certain properties while coming at the expense of others. The key constraints discussed are client-server architecture, statelessness, uniform interface, and layered system. Each constraint both provides benefits like simplified servers, scalability, and decoupling, while incurring costs like reduced efficiency or increased latency. The document also discusses using hypermedia and link relations to implement RESTful services in a loosely coupled way and avoid hard-coding URIs.

1. REST on steroids
By Andrei Nefyodov

2. Representational State Transfer(REST) — set of architectural constraints
Constraint Promotes At the expense of
Client-server ●UI portability
●Simplified server
●Multiple organizational domains
Stateless ●Simplifiied server Efficiency
●
●Scalability
●Reliability
Optional non-shared ●Reduced latency Reliability
●
caching ●Efficiency
●Scalability
Uniform interface ●Visibility Efficiency
●
●Independent evolution
●Decoupled implementation
Layered system ●Shared caching Higher latency
●
●Legacy encapsulation
●Simplified clients
●Scalability
●Load balancing
Optional code-on-demand ●Simplified clients Visibility
●
●Extensibility

3. Representational State Transfer(REST) — set of architectural constraints
Constraint Promotes At the expense of
Sub-constraints:
Client-server ●UI portability
● Identification of resources
●Simplified server
● Manipulation via representations
●Multiple organizational domains
● Self-descriptive messages
● Hypemedia as the engine of application state
Stateless ●Simplifiied server ●Efficiency
●Scalability
●Reliability
Optional non-shared ●Reduced latency ●Reliability
caching ●Efficiency
●Scalability
Uniform interface ●Visibility ●Efficiency
●Independent evolution
●Decoupled implementation
Layered system ●Shared caching ●Higher latency
●Legacy encapsulation
●Simplified clients
●Scalability
●Load balancing
Optional code-on-demand ●Simplified clients ●Visibility
●Extensibility

4. Representational State Transfer(REST) — set of architectural constraints
Constraint Promotes At the expense of
Sub-constraints:
Client-server ●UI portability
● Identification of resources
●Simplified server
● Manipulation via representations
●Multiple organizational domains
● Self-descriptive messages
● Hypemedia as the engine of application state
Stateless ●Simplifiied server ●Efficiency
●Scalability
●Reliability
Optional non-shared ●Reduced latency ●Reliability
caching ●Efficiency
●Scalability
Uniform interface ●Visibility ●Efficiency
●Independent evolution
●Decoupled implementation You get these if
Layered system ●Shared caching
you use HTTP latency
●Higher
●Legacy encapsulation
as your application protocol
●Simplified clients
●Scalability
●Load balancing
Optional code-on-demand ●Simplified clients ●Visibility
●Extensibility

5. Representational State Transfer(REST) — set of architectural constraints
Constraint Promotes At the expense of
Sub-constraints:
Client-server ●UI portability
● Identification of resources
●Simplified server
● Manipulation via representations
●Multiple organizational domains
● Self-descriptive messages
● Hypemedia as the engine of application state
Stateless ●Simplifiied server ●Efficiency
●Scalability
●Reliability
Optional non-shared ●Reduced latency ●Reliability
caching ●Efficiency
●Scalability
Uniform interface ●Visibility ●Efficiency
●Independent evolution
●Decoupled implementation
Layered system ●Shared caching ●Higher latency
●Legacy encapsulation
●Simplified clients
●Scalability
●Load balancing
Optional code-on-demand ●Simplified clients ●Visibility
●Extensibility

6. Hypermedia
● Links in representations
● State navigations discoverable
HATEOAS — hypertext as the engine of
application state. We express allowed state
transitions through links.

7. ● Hypermedia constraint is an often-overlooked
part of being RESTful
● Using Hypermedia aware media type such as
collection+json, XHTML promotes
➢ Loose coupling between client and server
➢ Simple documentation of semantic concepts
➢ Discoverability / testability / operability via
«API surfing»
● Much of the client framework is reusable

8. ● RESTBucks
● Starbucks (like) coffee ordering
● Order/payment
5 6
Preparing Ready Completed
4
2
1
Payment
expected
3
Cancelled

9. Method URI Action Step
POST /orders Create new order 1
PUT/PATCH /orders/4711 Update the order 2
(only if «payment
expected»)
DELETE /orders/4711 Cancel order 3
(only if «payment
expected»)
PUT /orders/4711/payment Pay order 4
Barista preparing the order
GET /orders/4711 Poll order state 5
GET /orders/4711/receipt Access reciept
DELETE /orders/4711/receipt Conclude the 6
order process

10. Challenges
How to avoid hard coding URIs?

11. Use link relations

12. Orders Returns all orders available in the system
Order Returns a single order
Self The uri value can be used to GET the latest resource representation
of the order.
Cancel This is the URI to be used to DELETE the order resource should the
consumer wish to cancel the order.
Update Consumers can change the order using a POST to transfer a
representation to the linked resource.
Payment The linked resource allows the consumer to begin paying for an
order. Initiating payment involves PUTting an appropriate resource
representation to the specified URI.
Receipt The URI to access the receipt using GET and conclude the order by
taking the receipt (use DELETE).

13. Method Relation type Action Step
POST orders Create new order 1
PUT/PATCH update Update the order 2
(only if «payment
expected»)
DELETE cancel Cancel order 3
(only if «payment
expected»)
PUT payment Pay order 4
Barista preparing the order
GET order Poll order state 5
GET receipt Access reciept
DELETE receipt Conclude the 6
order process

14. Challenges
How to implement «only if payment
expected»?

15. We can only navigate a link once it was
returned by the server

16. Place order
● Access root resource
{ links : [ { rel : "orders",
href : "…/orders" }]
}
● Follow orders link
$.links[?(@.rel="orders")].href
● POST /orders

17. {
links : [{
rel : "self",
href : "…/orders/4711"
},
…
…
{
rel : "payment",
href : "…/orders/4711/payment"
} ],
content : {
items : [{
drink : "Cappucino",
size : "large",
milk : "semi"
price : 4.2
}
],
location : "take-away",
price : 4.2
status : "payment expected"
}
}

18. Trigger payment
● Follow payment link
● $.links[?(@.rel="payment")].href
● PUT /orders/4711/payment

19. {
links : [{
rel : "self",
href : "…/orders/4711/payment"
}, {
rel : "order",
href : "…/orders/4711"
}
],
content : {
creditCard : [{
number : "1234123412341234",
cardHolder : "Ivan Ivanov",
expiryDate : "2013-11-01"
}
],
amount : {
currency : "EUR",
value : 4.2
}
}
}

20. Poll order
● Follow order link
$.links[?(@.rel="order")].href
● GET /orders/4711
● ETag / If-None-Match

21. {
links : [{
rel : "self",
href : "…/orders/4711"
}
],
content : {
items : [{
drink : "Cappucino",
size : "large",
milk : "semi"
price : 4.2
}
],
location : "take-away",
price : 4.2
status : "preparing"
}
}

22. {
links : [{
rel : "self",
href : "…/orders/4711"
}, {
rel : "receipt",
href : "…/orders/4711/receipt"
}
],
content : {
items : [{
drink : "Cappucino",
size : "large",
milk : "semi"
price : 4.2
}
],
location : "take-away",
price : 4.2
status : "ready"
}
}

23. Access receipt
● Follow receipt link
● $.links[?(@.rel="receipt")].href
● GET /orders/4711/receipt
Conclude order
● Follow receipt link
● $.links[?(@.rel="receipt")].href
● DELETE /orders/4711/receipt

24. DEMO

25. Summary
● Hypermedia — is often overlooked constaint of REST. In exchange you
get independent evolution and decoupled implementation.
● Spring HATEOAS - http://bit.ly/spring-hateoas
● Representation models
● LinkBuilderAPI
● Representation enrichment
● Spring Data REST - http://bit.ly/sd-rest
● Exports JPA repositories as resources
● Hypermedia driven representations
● Extension points
● REST Shell - github.com/SpringSource/rest-shell
● Explore REST webservices
● Hypermedia driven
● Spring HATEOAS link format
● Spring RESTBucks - http://bit.ly/spring-restbucks
● Sample implementation
● Using Spring technologies
● Lombok — projectlombok.org
• get rid of boilerplate

26. QUESTIONS?