Best Practice in API Design

6,535 views

Published on

"Best Practice in API Design" talk given at phpday 2012 in Verona, Italy. This talk aims to give the best possible advice to anyone publishing a web service of any kind.

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,535
On SlideShare
0
From Embeds
0
Number of Embeds
1,690
Actions
Shares
0
Downloads
80
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

Best Practice in API Design

  1. 1. Best Practice in API Design
  2. 2. About Me • Lorna Jane Mitchell • http://lornajane.net • PHP consultant, developer, trainer • Author, speaker 2
  3. 3. Using APIsThere are various stages: 1. publish 3
  4. 4. Using APIsThere are various stages: 1. publish 2. dogfood 3
  5. 5. Using APIsThere are various stages: 1. publish 2. dogfood 3. modularity 3
  6. 6. Web
  7. 7. Service
  8. 8. Design
  9. 9. Web
  10. 10. HTTP
  11. 11. Request and Response
  12. 12. Statelessness
  13. 13. Status Codes
  14. 14. Status Codes: Headline NewsCommon codes: 200 OK 302 Found 301 Moved 401 Not Authorised 403 Forbidden 404 Not Found 500 Internal Server Error 12
  15. 15. Headers
  16. 16. HTTP HeadersHeaders are the metadata about the content we send/receiveUseful headers: • Accept and Content-Type: used for content format negotiation 14
  17. 17. Content Negotiation
  18. 18. HTTP HeadersHeaders are the metadata about the content we send/receiveUseful headers: • Accept and Content-Type: used for content format negotiation • User-Agent: to identify what made the request 16
  19. 19. HTTP HeadersHeaders are the metadata about the content we send/receiveUseful headers: • Accept and Content-Type: used for content format negotiation • User-Agent: to identify what made the request • Set-Cookie and Cookie: working with cookie data 16
  20. 20. HTTP HeadersHeaders are the metadata about the content we send/receiveUseful headers: • Accept and Content-Type: used for content format negotiation • User-Agent: to identify what made the request • Set-Cookie and Cookie: working with cookie data • Authorization: controlling access 16
  21. 21. Access Control
  22. 22. Verbs
  23. 23. HTTP Verbs • More than GET and POST • PUT and DELETE to update and delete in a RESTful service • HEAD, OPTIONS and others also specified GET Read POST CreateIn REST, we use: PUT Update DELETE Delete 19
  24. 24. Service
  25. 25. Target Audience
  26. 26. Heartbeat
  27. 27. RPC Services
  28. 28. RPC: Remote Procedure Call • Single endpoint • Function name • Parameters • Return value • SOAP is a kind of RPC 24
  29. 29. Soap
  30. 30. Data Formats
  31. 31. Small APIs
  32. 32. REST
  33. 33. RESTful Services • REpresentational State Transfer • URLs are unique resource identifiers • HTTP verbs indicate which operation should happen • We have full CRUD operations on a series of resources 29
  34. 34. Design
  35. 35. Versioning
  36. 36. Consistency
  37. 37. Handling Errors
  38. 38. Delivery and Support
  39. 39. Web Service Design
  40. 40. Thanks! https://joind.in/6385 @lornajane http://lornajane.net/ 36

×