R.I.P.: REST in peace! A guide through RESTful services.

I did this presentation in the #9 Superplayer Hack Sessions.

Transcript

1. R.I.P.: REST IN PEACE! a guide through RESTful services
2. WHY REST ?
3. WHY REST ? well known concepts optimised technologies and infrastructure lightweight approach better scale
4. WHAT REST DO NOT MEANS
5. WHAT REST DO NOT MEANS REST is NOT a framework REST is NOT a protocol REST is NOT SOA REST is NOT Client-Server Architecture REST is NOT a URI REST is NOT API
6. WHAT REST MEANS ?
7. REST IS ABOUT STYLE
8. the REST creator
9. Roy Fielding== Roy Rosello
10. ROY's WORK … Architectural Styles and the Design of Network-based Software Architectures REpresentational State Transfer is a architectural style for distributed hypermedia systems HTTP spec & Apache HTTP server
11. REST CONSTRAINTS
12. REST CONSTRAINTS CLIENT-SERVER STATELESS RESOURCES
13. STATELESS each request contains all of the information and cannot take advantage of any stored context on the server session state is kept entirely on the client
14. RESOURCES the key abstraction of information in REST is a resource a resource IS NOT an API or ENDPOINT or METHOD
15. RESOURCE IDENTIFIER Uniform Resource Identifier (URI) the key to access the resource { protocol } : { base uri } / { resource path }
16. URI IS NOT an URL or URN but it covers it uniform resource locator uniform resource name
17. REST APIs BEST AND WORSE PRACTICES
18. NOUNS, NO VERBS
19. NOUNS, NO VERBS Leave verbs for the HTTP verbs /playlists /playlists/10 /getAllPlaylists /getPlaylist?id=10 /get?type=playlist&id=10 good bad
20. HTTP VERBS TO MEAN SOMETHING
21. GET /playlists GET /playlists/10 POST /playlists PUT /playlists/10 DELETE /playlists/10 HTTP VERBS TO MEAN SOMETHING
22. HTTP GET SHOULD NOT ALTER THE STATE
23. use POST, PUT and DELETE. also do not use GET when you HAVE no choice GET /subscriptions/171/cancel // bad PUT /subscriptions/171/cancel // bad but better ... HTTP GET SHOULD NOT ALTER THE STATE
24. HTTP STATUS CODE
25. for successful requests, use 2xx status code. when the client is wrong, use 4xx status code. for unknown errors, use 5xx status code HTTP STATUS CODE
26. HTTP HEADERS FOR SERIALIZATION FORMATS
27. Accept: application/json prefer JSON. HTTP HEADERS FOR SERIALIZATION FORMATS
28. VERSIONING
29. prefer /v1, /v2 Instead of /1.0 /v1.0 /20141201 the version is part of the base URI VERSIONING
30. ERROR HANDLING
31. use a standard structure for error messages always identify the error with a key/code. ERROR HANDLING
32. THE ZOMBIES FAMILY
33. THANKS speakerdeck.com/robsondealmeida /robsondealmeida /robsondealmeida