This presentation aimed to explain what is REST and why it is commonly misunderstood. It focuses on describing REST from scientific point of view, based on Roy`s Fielding dissertation.

1. Representational
State Transfer
Alexei Skachykhin – Software Engineer
iTechArt, 2014

2. The Internet Of Things
 Explosion of WWW
 Smart Electronics
 Web APIs

3. Painting Style
What painting
style is it?
Cubism? Surrealism?

4. REST
Like painting style, REST is a network architectural style
Representational State Transfer

5. REST
NO SPEC! NO PROTOCOL!

6. Who coined the term?
Roy Fielding
 Author of HTTP spec
 Co-founder of Apache HTTP Server
 Senior Principal scientist at Adobe

7. Who else?
Mike Amundsen Leonard Richardson

8. Architectural Style
Architectural style is basically set of constraints, and
following them leads to gaining certain
architectural properties (benefits)

9. Architectural Style
Feature-driven
Architectural Style

10. Architectural Style
Constraints-driven
Architectural Style

11. Properties of REST
Heterogeny Scalability Evolvability
Visibility Reliability Efficiency

12. Constraints
Client-Server Stateless Cacheable
Layered
System
Code on
Demand
Uniform
Interface
 Optional constraint

13. REST Derivation
RR CS LS VM U
$ CSS LCS COD
C$SS LC$SS LCODC$SS REST
layered
on-demand stateless simple
visible
reliable shared extensible reusable
scalable multi.
org.

14. Client-Server
 Separation of concerns
 Independent development
 Security is scoped to connections
Benefits

15. Client-Server
Wouldn`t that mean that Client-Side
databases violate REST?
NOT AT ALL ACTUALLY

16. Client-Server
How does WebRTC fit into REST?
IT DOESN`T

17. Stateless
Each request from client to server must
contain all of the information necessary to
understand the request

18. Stateless
Application
State
Resource
State

19. Stateless
 Simplified Scalability (CAP theorem)
 Improved Reliability (recover from failures)
 Visibility
Benefits

20. Stateless
 Performance decrease (repetitive data)
 Risk of inconsistent app behavior
Disadvantages

21. Cacheable
Cache constraints require that the data within a
response to a request be implicitly or explicitly
labeled as cacheable or non-cacheable

22. Cacheable
 Improved efficiency
 Improved scalability
 Improved user perceived performance
Benefits

23. Layered system
Allows an architecture to be composed of
hierarchical layers

24. Layered system
 Bound complexity
 Improved scalability (load balancing)
Benefits

25. Layered system
 Increased latency
 User-perceived performance may degrade
Disadvantages

26. Code on Demand (Optional)
REST allows client functionality to be extended
by downloading and executing code in the form
of applets or scripts

27. Code on Demand (Optional)
 Improved extensibility
 Simplified clients
Benefits

28. Uniform Interface
Generalized interface between components.
All of the components communicate through
this interface

29. Uniform Interface
 Improved visibility
 Overall simplicity
 Implementation decoupled from services
Benefits

30. Uniform Interface
BUT!
Performance suffers!

31. Uniform Interface
Identification of
resources
Manipulation of
resources through
representations
Self-descriptive
messages
Hypermedia as the
engine of application
state

32. Uniform Interface
Resources
Resource is any concept that might be target
of an author`s hypertext reference

33. Uniform Interface
Resources
DOCUMENT, IMAGE, PERSON, COLLECTION OF
FAVOURITE MOVIES, E.T.C.

34. Uniform Interface
Resources
 𝑀 𝑟 𝑡 , resource to set map
 Static semantics
 Many-to-Many

35. Uniform Interface
Resources
Don`t use database schema as a basis for
Web API for couple of reasons
 API clients care about application semantics not database
schema, which is different thing
 Changes to the database schema become impossible

36. Uniform Interface
Resource Identification
Not a word about URL format!
It doesn`t matter!

37. Uniform Interface
Resource Identification
Hardcoded URLs or URL
templates is a form of coupling!

38. Uniform Interface
Resource Identification
URI Templates (RFC 6570)
http://example.org/~{username}/{term:1}/{term}{?q*,lang} {
username: "rodneyrehm",
term: "hello world",
q: {
a: "mars",
b: "jupiter“
},
lang: "en"
}
+
http://example.org/~rodneyrehm/h/hello%20world?a=mars&b=jupiter&lang=en

39. Uniform Interface
Manipulation of resources through representations
A representation is a sequence of bytes, plus
representation metadata to describe those bytes.
Representation captures the state of resource.

40. Uniform Interface
Manipulation of resources through representations
 Can be any sequence of bytes
 Resource can have multiple representations
 Content negotiation is needed

41. Uniform Interface
Manipulation of resources through representations
Do I violate REST if I pick HTML as
representation format?
NO YOU DON`T

42. Uniform Interface
HATEOAS
HATEOAS!
Is it a Greek got?

43. Uniform Interface
HATEOAS
Hypermedia as the engine of
application state!

44. Uniform Interface
HATEOAS
You already know about
Application State, right?
At least I told you 10 minutes ago :)

45. Uniform Interface
HATEOAS
Hypermedia connects resources to each
other, and describes their capabilities in
machine-readable ways

46. Uniform Interface
HATEOAS
What to do next?

47. Uniform Interface
HATEOAS
What to do next?
{
"appnews": {
"appid": 440,
"newsitems": [{
"gid": "3189986872441392984",
"title": "Team Fortress 2 Update Released",
"url": "http://store.steampowered.com/news/13634/",
"is_external_url": false,
"author": "Valve",
"feedlabel": "Product Update",
"date": 1402535460,
"feedname": "steam_updates“
}]
}
}

48. Uniform Interface
HATEOAS
“Hypermedia connects resources to each
other, and describes their capabilities in
machine-readable ways”
- Roy Fielding

49. Uniform Interface
HATEOAS
Most of the “RESTful” Web APIs are not
RESTful, because of lack of hypermedia

50. Uniform Interface
HATEOAS
 Decoupling between client and server
 Resilience to API changes
 Enhanced usability (no hardcode and doc issues)
Why hypermedia is important for Web APIs?

51. Uniform Interface
Hypermedia Aware Media Types
Siren – generic
hypermedia format
{
"class": ["owner", "vip"],
"properties": {
"name": "Kevin“
},
"entities": [
{
"rel": ["https://rels.x.io/dog"],
"href": https://api.x.io/dogs/1
}
],
"actions": [
{
"name": "adopt",
"method": "POST",
"href": "https://api.x.io/owners/1/dogs",
"fields": [{ "name": "dog-name", "type": "text" }]
}
],
"links": [
{ "rel": ["self"], "href": "https://api.x.io/owners/1" }
]
}
LinkLink Relation

52. Uniform Interface
Hypermedia Aware Media Types
SIREN, HAL, COLLECTION+JSON, JSON-LD,
HYDRA, OData, AtomPub, HTML
 W3C Spec

53. Uniform Interface
HATEOAS
Not a word about URL format!
It doesn`t matter!

54. Uniform Interface
HATEOAS
Hardcoded URLs or URL
templates is a form of coupling!

55. REST Flavor
“REST is software design on the scale of decades:
every detail is intended to promote software longevity
and independent evolution. Many of the constraints
are directly opposed to short-term efficiency”
- Roy Fielding

56. HTTP only?
REST is not bound to HTTP
Other implementations are: CoAP, Waka

57. Richardson Maturity Model
Not only verbs
but all HTTP
facilities

58. Richardson Maturity Model
Don`t reinvent the wheel, stick with capabilities of
application protocol of your choice (HTTP mostly)
HTTP Verbs, Status Codes, Headers

59. REST Religion
REST is not a religion! Treat it as a reference
network architecture of the Web

60. Links
Roy`s Fielding dissertation:
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
API Academy:
http://www.apiacademy.co/
Parse.com
https://parse.com/
Hypertext Driven API:
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

61. Thank you!
Forward your questions to
alexei.skachykhin@live.com