REST Clients Nordic APIs

On this presentation I talk about how writing an API can help you accelerate your clients development and business development efforts.

The second half I share some patterns that we discovered while building clients for Redbooth.

Transcript

1. REST Clients
2. CTO at Redbooth ! @masylum on both Github and Twitter
3. • Tasks • Conversations • Documents and files • Chat
4. • Web Client • iOS Client • Android Client • GMail and Outlook plugins
5. One API to rule them all
6. Business development “for free”
8. Drawbacks?
9. • Render on the client • More Integration test • Backward compatibility • Coordinate API and client implementations
10. REST is not dead despite exaggerated hypermedia rumors
11. REST tells you how to build and consume your API
12. Constraints set you free
15. Development in parallel
17. Beware!
18. Stateful is hard: Server and client’s state will diverge
20. Side effects? Can be RESTful too
21. Use POST for RPC actions ! http://restful-api-design.readthedocs.org/ en/latest/methods.html#actions
22. POST /api/3/channels/9/mute HTTP/1.1 Host: redbooth.com ! { “for”: “1-hour” } ! Simplified Response ! {“id”: 9, “muted_until": 1413735462} !
23. Use the Link HTTP header to tell the client to re-fetch a resource http://www.w3.org/wiki/LinkHeader
24. POST /api/3/comments HTTP/1.1 Host: redbooth.com ! { “body”: “This task is for @bpedro” } ! Response Contains ! Link:<https://redbooth.com/api/3/tasks/ 15065399>; rel="updated" type="Task">
25. Minimize impact of race conditions with PATCH instead of PUT
26. You are using PATCH wrong. Try JSON-MERGE ! http://tools.ietf.org/html/draft- ietf-appsawg-json-merge-patch-07
27. PATCH /my/resource HTTP/1.1 Host: example.org Content-Type: application/merge-patch+json ! { "title": "Hello!", "author": { "familyName": null } }
28. For complex resources try JSON-PATCH ! http://tools.ietf.org/html/rfc6902
29. PATCH /my/resource HTTP/1.1 Host: example.org Content-Type: application/json-patch+json ! [ { "op": "remove", "path": "/a/b/c" }, { "op": "add", "path": "/a/b/c", "value": "foo"}, { "op": "replace", "path": "/a/b/c", "value": 42 } ]
30. Nested resources are troublesome
31. Bet on “flat” APIs
32. Perceived speed
33. Pessimist vs optimist clients
34. Be pessimist : • Hard to rollback • Hard to predict the response
36. Be optimist otherwise
38. Asynchronous operations
39. Respond with 202 and one token so the client can poll
40. Offline and Caching strategies
41. Avoid it if possible
42. What if I have to?
43. Expose your API’s cache
44. Store the data and the cache’s timestamp. Next time request only changes and merge them.
45. Final thoughts
46. Build an API for the clients
47. REST allows server and client implementors work more efficiently
48. Explore new specs and trends but “don’t drink too much kool-aid"
49. Thanks for listening. ! We are hiring!