6. Good practices
• Though not so universal
• http://blog.feedly.com/2009/05/06/best-
practices-for-building-json-rest-web-
services/
• http://jacobian.org/writing/rest-worst-
practices/
6
7. Writing spec
Document it first
• Real use-cases
• Complete and closed set
• Future kills now
• Explicit versioning
7
8. Beginners mistakes
• Resource = model
• Think about married couple
• All methods should be implemented for
every resource
• Update user account activation? Delete
sent SMS message?
• Custom methods
8
9. Use nouns
(learn passive voice)
• User sends SMS message =>
A SMS message is created
• Article is reviewed by editor =>
Review of article is created
• The user deactivates account =>
User account activation is deleted
9
14. Real world sample 0
• SMS Gate
• GET http://smsgate/sendMessage?
number=780020000000&text=Send+it
+please
14
15. Real world sample
• SMS Gate
• Resource: Text Message /message:
• Create new one (send) —
POST /messages
• Get information about status
GET /messages/{id}
• version: 2
15
16. Real world sample 2
• POST https://smsgate2/v2/messages
> message=Send%20it
%20please&target=780020000000
• 201 Created
Location: https://smsgate2/v2/messages/242
{‘target’: ‘78002000000’, ‘url’: ‘https://
smsgate2/v2/message’, ‘status’: ‘queued’}
16
19. Toolset: prototyping
• Red barrel
• External DSL (hello, PHP&Ruby)
• Self-documented
• Easy to distribute
• Only for prototyping
19
20. Flask
• Simple
• You get what you need
• A lot of bootstrapping code
• Attention to details
• Chance to get hardcoded result
• In our projects most load-intensive APIs are
implemented using Flask
20
21. Django+Piston
• Good set of features (for that time)
• Built-in formatters
• works well, on Accept header
• Methods are strictly mapped to actions
• Hard to reuse different forms in single
handler
• It’s obsolete
21
22. Django+TastyPie
• A lot of features
• Pure Resource, ModelResource
• Pagination
• In our team richest APIs are implemented
in TastyPie
22
