REST è lo stile architetturale a cui aderisce quello che oggi noi chiamiamo Web. Uno dei problemi storici della programmazione di applicazioni web è l’impendance mismatch fra vari modelli computazionali e di dati (REST, Object Oriented, Relational Model, ecc…). Questa sessione ha lo scopo di evidenziare la problematica con relativi esempi, soluzioni e risultati ottenuti con l’utilizzo di PHP.

1. REST and
Resource Oriented
Architectures
Gabriele Lana
gabriele.lana@gmail.com

2. what is
REST?

3. REST is not
a Protocol
an Architecture
a Software
a Standard
a fancy name for Web Services
a Buzzword

4. Representational
State
Transfer
Roy T. Fielding
“Architectural Styles and the Design of Network-based Software Architectures”
Ph.D dissertation, 2000

5. REST is
a Software Architecture Style
a set of Constraints on Component
Interaction that, when obeyed, cause
the resulting Architecture to have
certain properties
Roy T. Fielding http://roy.gbiv.com/untangled/2008/on-software-architecture

6. ?

7. prediction for 2009
“Roy Fielding will officially disown most of the
RESTful authors and software packages
available. Nobody will care, or worse, somebody
looking to make a name for themselves will
proclaim that “Roy doesn't really understand
REST”, and they'll be right: Roy doesn't
understand what they consider to be REST”
http://dotnet.dzone.com/articles/ted-neward-2009-predictions-20

8. why?
“... the motivation for developing REST was to
create an architectural model for how the Web
should work, such that it could serve as the
guiding framework for the Web protocol
standards”
http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm

9. no Silver Bullets
REST vs
SOA vs
SOAP vs
RPC vs
WS-* vs
...

10. but sometimes
REST is better :-)

11. web applications
Information Flow
RDB
HTTP
OOP MS

12. HTTP is REST
RDB
HTTP
OOP MS

13. Impedance
Mismatch
RDB
HTTP
OOP MS

14. Accidental
Complexity
RDB
HTTP
OOP MS

15. Essential
Complexity
RDB
HTTP
OOP MS

16. RDB
RPC OOP MS
HTTP
RPC

17. Resource Oriented
Architectures
RDB
HTTP ROA
MS

18. maybe not today,
but Yes, we Can
HTTP ROA DATA

19. REST by Example
(Chess)

20. how to Design a
RESTful service
Step by Step
Leonard Richardson & Sam Ruby “RESTful Web Services”, O’Reilly 2007

21. 1. every Resource
must be Identified

22. Pawn Move Bishop
Game Player
Rank
Board Rook
File
Knight
Position
Queen Square

23. every Concept in
your Domain can
be a Resource

24. 2. design the URIs
(Ubiquitous Language)

25. /position/wqd3,wkd1,bqd7,bkd8

26. /position/wqd3,wkd1,bqe6,bkf8/d3-d8

27. /move/wqd3,wkd1,bkf8-wqd8,wkd1,bkf8

28. /position/initial

29. /board/4815162342
/position/wqd3,wkd1,bqe6,bkf8
move = d3-d8
/position/wqd8,wkd1,bqe6,bkf8

30. /player/50298

31. 3. for each Resource
expose a subset of
the Uniform Interface

32. Uniform Interface
GET (Read)
POST (Create)
PUT (Update)
DELETE (Delete)

33. GET /player/50298 HTTP/1.1
Retrieve informations
on identified Resource
Idempotent,
should not change
the Resource State

34. POST /position/wqd3,wkd1,bke8 HTTP/1.1
n
move = d3-d8
HTTP/1.1 302 Found
Location: /position/wqd8,wkd1,bke8
POST to let Resources
process informations

35. POST /game HTTP/1.1
n
white = /player/50298 &
black = /player/39650
HTTP/1.1 201 Created
Location: /game/42
POST to Create
new Resources

36. PUT /board/4815162342 HTTP/1.1
n
position = /position/wqd3,wkd2,bke8
HTTP/1.1 205 Reset Content
PUT to Update
Resource Informations

37. PUT /position/wqd3,wkd1,bke8 HTTP/1.1
n
position = /position/wqd3,wkd2,bke8
HTTP/1.1 405 Method Not Allowed
a Method can be
not supported by a Resource
but should not be ignored

38. DELETE /board/4815162342 HTTP/1.1
HTTP/1.1 204 No Content
DELETE to
logically Remove
Resources

39. 4. for each Resource
design Representations
from and to Client

40. GET /position/wqd3,wkd2,bke8 HTTP/1.1
Accept: text/plain
HTTP/1.1 200 OK
Content-Type: text/plain;format=fen
n
3k4/8/3q4/8/8/8/8/5K2
client/server Content Negotiation
(MIME properties)

41. GET /position/wqd3,wkd2,bke8 HTTP/1.1
Accept: image/png;q=0.8, text/plain;q=0.2
HTTP/1.1 200 OK
Content-Type: image/png
n
PNG...
client/server Content Negotiation
(Preferences)

42. GET /position/wqd3,wkd2,bke8.png HTTP/1.1
Accept: image/png
HTTP/1.1 200 OK
Content-Type: image/png
n
PNG...
client Explicit Request of
Content-Type

43. GET /position/wqd3,wkd2,bke8.gif HTTP/1.1
Accept: image/gif
HTTP/1.1 406 Not Acceptable
or more friendly
HTTP/1.1 300 Multiple Choices
Content-Type: application/xml
n
<choices><content type=”image/png” uri=”...”>

44. GET /game/42 HTTP/1.1
Accept: application/vnd.dharma.chess
<game>
<player role=”white”>/player/1001</player>
<player role=”black”>/player/1002</player>
<moves>
<position>/position/initial</position>
</moves>
</game>
custom Content-Type

45. wait...
what about
plain old
Web Applications?

46. GET /game/42 HTTP/1.1
Accept: application/xhtml+xml
<html>
... <a rel=”owner” href=”/player/1001”>...</a> ...
<ul class=”moves”>
<li><image src=”/position/initial.png”/></li>
</ul>
</html>
Semantic Web is not a dream

47. Tim Berners-Lee
on Linked Data
“... almost 20 years ago I wanted
to reframe the way we use
informations ... I invented the
Word Wide Web ... now is time
for a new reframing...”
Tim Berners-Lee @ http://linkeddata.org

48. expected behavior of the web
1. Use URIs as names for things
2. Use HTTP URIs so that people
can look up those names
3. When someone looks up a URI,
provide useful information
4. Include links to other URIs, so
that they can discover more things

49. POST /game/42 HTTP/1.1
Content-Type: application/vnd.dharma.chess
Authorization: Basic dXN1cm5hbWU6cG...
n
<game>
<player>...</player>
<moves>
<position>/position/initial</position>
<position color=”white”>
/position/wra1,wna2,...,wpd4,...
</position>
</moves>
</game>
... from and to the Client

50. 5. design
typical flows
and
error
conditions

51. POST /game/42 HTTP/1.1
Content-Type: application/vnd.dharma.chess
Authorization: Basic dXN1...
n
<game>
<player>...</player>
<moves>
<position>/position/initial</position>
<position color=”white”>
/position/wra1,wna2,...,wpd4,...
</position>
</moves>
</game>
white Player make first move

52. HTTP/1.1 201 Created
Location: /game/42/position/2
Response to the white Player
GET /game/42/position/2
HTTP/1.1 301 Moved Permanently
Location: /position/wra1,wna2,...,wpd4,...

53. GET /game/42 HTTP/1.1
Authorization: Basic dXN1...
n
<game>
<player>...</player>
<moves>...</player>
</game>
GET /game/42 HTTP/1.1
Authorization: Basic aYR5...
n
<game>
<player>...</player>
<moves>...</player>
</game>
both Players must GET
the game Representation

54. POST /game/42 HTTP/1.1
Content-Type: application/vnd.dharma.chess
Authorization: Basic aYR5...
n
<game>
<player>...</player>
<moves>
<position>/position/initial</position>
<position>/position/wra1,wna2,...,wpd4,...</position>
<position color=”black”>
/position/wra1,wna2,...,bpd5,...
</position>
</moves>
</game>
black Player can make next move

55. POST /game/42 HTTP/1.1
Content-Type: application/vnd.dharma.chess
Authorization: Basic aYR5...
n
...
what if black Player try to resend?
HTTP/1.1 409 Conflict
the game Representation is
out of date

56. POST /game/42 HTTP/1.1
Content-Type: application/vnd.dharma.chess
Authorization: Basic aYR5...
n
...
what if black Player try to move again?
HTTP/1.1 403 Forbidden
the black Player should wait
for the white Player to move

57. POST /position/wqd3,wkd1,bke8 HTTP/1.1
n
move = d3-e8
what if we try to make a wrong move?
HTTP/1.1 404 Not Found
Business Rules could be easily
expressed through the Resource's
Behavior

58. wait...
what about
complex User
Interfaces?

59. what about Gmail

60. what about Gmail
JS
HTTP
? JS

61. what about Gmail

62. FAQ: cool URIs
are RESTful?
OpenSocial
/people/{guid}/@all
Collection of all people connected to user {guid}
http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/restful-protocol.html

63. FAQ: REST is
stateless?
Statelessness says that
all possible states of the server
are also Resources
(Resource State)

64. FAQ: REST is
stateless?
Statelessness says that
each message contains
all the informations necessary
to understand the Request
(Application State)

65. Representational State Transfer
Application
State
R3
R4
R2
R1
CLIENT
SERVER
Resource
State

66. your application
can be Discoverable

67. your application
can be Testable

68. Testability
View Model
Control
HTTP

69. Testability
too much code untested
View Model
Control
HTTP

70. Testability
too fragile and unreliable
View Model
Control
HTTP

71. Testability
Player
Board
Position
Game
Move
Js
HTTP

72. Testability
what about the view?
Player
Board
Position
Game
Move
Js
HTTP

73. your application
can be Composable

74. your application
can be Scalable

75. ...so what Really
means (for me)
being RESTful?

76. now the Web
can talk about
chess