Api anti patterns


Published on

API Patterns are boring, API Anti-Patterns are not.

Delivered at PHPLondon on 5th Aug 10'

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

  • Welcome to PHPLondon August 2010 meetup.
    I’m here to talk about API Antipatterns and, more specifically, the use of REST.
  • or, some great ways to piss off your customers and users.
  • or, I’m going to teach you to suck eggs.
  • or, we’ll just laugh at other peoples’ expense.
  • So, hello, thanks for coming, you’re all wonderful, really.
  • My name is Mike Pearce, this is my avatar, you’ll see it liberally splashed about on various social networks.
  • You can usually find me as ‘MikePearce’ on most networks.
  • or ‘MikeyPearce’
  • or even mikepearce.net
  • but, mostly MikePearce. I work for Affiliate Window, although I’ve only been there two days, so don’t ask me anything about them. Anyway, my contact details will be at the end if you’re still awake, or even still here...
  • Firstly an apology. this presentation is ill written, probably badly researched and definately un-rehearsed. I only had a couple of weeks notice and most of that time was already taken up with things like working, eating sleeping and high-maintenance children.
  • I also went to a festival, Sonisphere at Knebworth
  • I ate too much
  • Drank too much
  • and everything I had ever learned about my job fell out of my head for four days. Monday arrived, then Tuesday and I still hadn’t done it.
  • So, along with starting a new job, I’ve spent the last 48hours glued to Keynote.
  • Anyway, I shall get on with it now.
  • You probably think I am here to talk about REST, right?
  • Well, I’m not.

  • Actually, I am ... sort of. I’m here to talk about how NOT to do rest, which is much easier!

  • The do’s, the dont’s and the whatevs of a REST API.

  • Roy Fielding is a 45 year old Californian who ...
  • Is one of the principle authors of the HTTP 1.1 RFC
  • He also wrote a dissertation in 2000 called ‘Architectural Styles andthe Design of Network-based Software Architectures’ for a doctorate of philosophy. Hands up who has read this!

  • ... and chapter 5 had all the meaty stuff about REST.

  • Rest isn’t HTTP ...
  • and REST isn’t ‘The Web’. I’ve heard REST summarised as Roy Fielding’s way of describing the existing architecture of the web. While this is true, that’s not all it is. REST principles can be applied with many other technologies.
  • REST isn’t particularly hard to get right.
  • REST isn’t particularly hard to get right.
  • REST isn’t particularly hard to get right.
  • REST isn’t particularly hard to get right.
  • There aren’t really any standards.
  • Just a few constraints and a couple of guidelines.

    http://www.flickr.com/photos/joe_13/19946186/ joe_13
  • REST is really a set of verbs
  • which are applied to nouns.

    Here is a short example...
  • JON, can you
  • me a pint

  • So, let’s get into the anti patterns.
  • So, the first antipattern and these aren’t in any particular order is..
  • http://www.flickr.com/photos/23846880@N00/391925649/ Rutger de Moddertukker

  • Probably one of the most obvious, yet most abused pattern is to use GET or POST for everything. As I mentioned earlier, REST is about applying verbs to nouns. The nouns HTTP has are few, granted, but still distinct enough to each have their own jobs.


  • TRACE - Echoes back the received request, so that a client can see what (if any) changes or additions have been made by intermediate servers.
    OPTIONS - Returns the HTTP methods that the server supports for specified URL. CONNECT - Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy
    PATCH - Is used to apply partial modifications to a resource.[8]

  • An example of GET tunnelling. While this is clear enough what’s it’s doing, it’s not adhering to a rest restraint, so, not really RESTful.
  • Good example of storing a document
  • PUT or POST is a question you’ll often ask yourself and it’s not always clear cut. Generally, you’ll use a PUT when you saving a document at a certain location or in a collection
  • and POST when you want the application to decide where to save the document.
  • It’s not clear cut though, so use your best judgements. Just remember that when you PUT a document at a location that it already exists at, you should PUT the entire original document, otherwise you should use UPDATE.
  • Here is an example of using POST to delete.
  • This is much better, it’s semantically correct and shorter to boot!
  • Next up, tunnelling all errors through 200 OK. This is one of my biggest beefs and something that’s caught me out as a consumer a couple of times now.
  • Anyone recognise this?

    When consuming the API of my wife, I ask her, ‘Are you OK?’ and she response with ‘Fine” which, in my head, is a 200 ok.

    http://www.flickr.com/photos/yourdon/2573762303/ - Ed Yourdon

  • Or this?

    From my wifes point of view.

  • The error I’m receiveing reflects the request I made. It’s not 200 OK not the droids you’re looking for. THAT would be confusing.

  • THIS is the most confusing and downright useless response I ever received from a Telco provider I worked with in my last job. A 200 OK code, with a plain text header and an XML body...
  • Which leads on nicely to response codes. There are many Response Codes that you can return which will provide the consumer with a much better idea of how to handle the body of the response. They fall broadly into five categories.
  • 1** information codes eg: continue, switching protocols
  • 2xx codes: 200 OK, 201 created, 202 accepted
  • 3xx redirection: 303 moved, 304 not modified

    http://www.flickr.com/photos/duchamp/126115989/ - Duchamp

  • 4xx codes: 404, 401 Unauthorised

    http://www.flickr.com/photos/thefangmonster/490423135/ - The fang monster
  • 5xx codes. Really, the crux of the matter here is use response codes that are relevant to the response you are sending.
  • A 200 OK is an appropriate response for a successful PUT request, but to really be on the ball...
  • ... send a 201 created!
  • You can also make up your own codes, if the standard ones really don’t cut it.
  • You can also make up your own codes.
  • One of the greatest benefits of using HTTP is caching. However, HTTP caching is complex and scary. You should use it where you can and encourage your clients to make use of ...
  • http://www.flickr.com/photos/epsos/4582789354/ - epSos.de
  • ETags
  • ETags are sent with the header and are a unique representation of that resource at that time. Collision-resistant has functions should be used to generate an etag, which is sent to the client. the client stores caches the etag along with the rest of the response, but the next time it makes a request to the URI, it sends an if-none-match header, which contains the original etag. The server will compare the two and, if nothing has changed, send a 304 (Can anyone tell me what a 304 is?) (Not Modified), otherwise, it will respond with the new data.

    More about caching is outside of the scope of this prez, talk to me afterwards if you want to know more (although, I don't know much more!).

  • Cookies, delicious right?

    By allie pasquier

  • Don't do it. If you have to, don't put server state data in them and don't authenticate with them. I have no idea yet how local storage will affect how I develop an API.
    http://www.flickr.com/photos/nickstone333/3135320160/ nickstone333

  • What is hypermedia?
  • What is hypermedia?
    Hypermedia is the sequel to Hypertext. Hypermedia includes audio, images, text and links.


  • HATEOAS: You should be able to access your API from a single URI and be able to traverse the entire API by just knowing the one URI. If you forget this, you're not taking advantage of one of the core concepts of REST. Your API is now self-documenting and can never be out of date. For example, what a consumer does: 
    GET: /users/MikePearce
    (assuming it's not cached) the API should return user information about me, but also information about how to modify me, how to delete me and links to other collections that have something to do with me. It should really also return a number of fixed URIs for adding collections.

    Or should it?

    That's one way of doing it, another way would be to publish one URI which lists all the features of the API and the URIs that you can access them with. Perhaps the endpoint as a start?

    Most clients will construct their own URIs, but mostly because they're never given any links to follow from the API in the first place! You can change this!
  • So, as always there are grey areas. The lack of any standards or an RFC for REST means that there's often areas of the discipline which, for some, offer the opportunity for wiggle room. The first of these, which you will see debated frequently (and there's some great discussions on Stack Overflow) is...

    http://www.flickr.com/photos/rdrcollection/116454033/ Rodney Ramsey
  • As with anything SAAS, your API will change over time and this means that some of your URIs may change. Now, the URI is the most prominent part of a RESTful API. It is something the users will use forever. It is a long term commitment to the user, so you have to get it right first time. However, there might be times when you absolutely have to change the way something works. For example, your initial design decision to make the URIs human readable means you might end up with a request like this:
  • But, you've now decided that you'd be better off requesting the user from their ID.
  • While less human readable, the margin for error is less. However, now all your consumers and clients are unable to query for both. You could program your API to look for strings AS WELL as integers, but it's going to get messy quickly. So, the best bet is to version. I'll explain a couple of methods for versioning, but you should decide what is best for you.

  • 3. No versioning at all (but with a 'sunset' period) (This is more difficult if the clients consuming your API are paying for it, or don't move very quickly, hence this becomes business decision, not a technical one.
  • Another grey area, but this one only really has two choices. How does your client request particular document type?

    http://www.flickr.com/photos/turatti/4526352835/ jaci xIII

  • You either use the .extension style...

  • or send Accept headers with your request. You should bare in mind though that some servers WILL cache old accept headers or, in some instances, completely ignore your Accept headers. So it’s probably safer to use .extensions
  • Summary.
  • Don’t use get and post for everything. There ARE other verbs to apply to your nouns.
  • Use appropriate error codes. If it’s an error, it’s not 200 OK (unless you were expecting and error code and 200 OK IS an error...)
  • Use appropriate response codes. A 201 created or 202 accepted is preferable to a 200 OK after a mutation.
  • Be responsible with caching. Suppy clients with an expiry time for the data you suppy and also encourage them to use etags
  • Only use cookies if you really have to and make sure they contain stateless data. Prefer HTTP Auth over cookie auth if you can.
  • Hate Oars, or, remember to provide links to other relevant parts of the API with your response. You can also provide a directory of URIs at your end point if you like.
  • Versioning is totally up to you, there are a few options, it depends on you and your clients’ needs.
  • Use “dot” extensions or an Accept header, perhaps even both for those proxies which don’t behave themselves.
  • Which leads on nicely to response codes. There are many Response Codes that you can return which will provide the consumer with a much better idea of how to handle the body of the response. They fall broadly into five categories.

  • My name is Mike Pearce, this is my avatar, you’ll see it liberally splashed about on various social networks.
  • Api anti patterns

    1. 1. API Anti Patterns or, how to not f**k up your API
    2. 2. API Anti Patterns or, how to not f**k up your API
    3. 3. or, tips on how to annoy your API consumers
    4. 4. or, think you know REST? Awesome!
    5. 5. or, some of the crazy s**t people do with REST
    6. 6. Hello
    7. 7. Mike Pearce
    8. 8. http://social-network.com /MikePearce
    9. 9. http://social-network.com /MikeyPearce
    10. 10. http://social-network.com /mikepearce.net
    11. 11. http://social-network.com /MikePearce
    12. 12. An Apology
    13. 13. RE HE h ISP ort S ON ebw @ Kn Flags shoul d be banne d a festival s!
    14. 14. Bu rritos: l. Food . Ever. Best. Festiva
    15. 15. Mike, Lee and Rog
    16. 16. SORRY
    17. 17. ( HTTP REQUEST: ) That you get on with it...
    18. 18. a mIh ere? Why REST
    19. 19. a mIh ere? Why REST
    20. 20. a mIh ere? Why REST Ha h!
    21. 21. a mIh ere? Why ST REST Hu h?!
    22. 22. Do’s ✔
    23. 23. Do’s ✔ Dont’s ✘
    24. 24. Do’s ✔ Dont’s ✘ Whatevs.. ☠
    25. 25. Some But fi rst... background
    26. 26. Who? Roy Fielding (the grandfather)
    27. 27. There!
    28. 28. Architectural Styles and the Design of Network- Can’t s ead tbased leep? his... Software R Architectures
    29. 29. A A nd now ... quick primer
    30. 30. REST != HTTP
    31. 31. REST != HTTP REST != The Web
    32. 32. REST
    33. 33. REST IS NOT
    34. 34. REST IS NOT HA
    35. 35. REST IS NOT Se HA riou sly!
    36. 36. Standards? We don’t need no steenkin’ standards!
    38. 38. e ve rbs... Som
    39. 39. e nou ns... Som
    40. 40. GET
    41. 41. PINT
    42. 42. PINT Plea se!
    43. 43. main event Ont o the ANTI patterns
    44. 44. Overuse of ...
    45. 45. GET
    46. 46. Overuse of GET and POST or, GET/POST tunnelling.
    47. 47. GET: BA http://api.flickr.com/services/ rest/?method= flickr.photos.people.add &api_key=nnn&photo_id=yyy&u ser_id=xxx
    48. 48. PUT: /user/MikePearce api_key=moo& age=33& size=medium& power=flight GOOD
    49. 49. PUT or POST? PUT: /users/MikePearce PUT: /links/google PUT: /articles/100805/putorpost ASIDE
    50. 50. PUT or POST? POST: /documents/save name=styleguide.css& category=design ASIDE
    51. 51. PUT or POST? PUT when the resource will live at the target URI POST when you want the server to handle the location of the resource. ASIDE
    52. 52. POST: /dostuff/ user=MikePearce& BA action=delete& api_key=moo& token=quack& mode=3
    53. 53. DELETE: /user/MikePearce Wait! W hat? Wh y!? GOOD
    54. 54. Tunneling Errors through
    55. 55. Are you OK? I’m fine! Great! A 200 OK!
    56. 56. Are you OK? I’m fine! Great! A 200 OK! ARGGHH! He doesn’t understand me!
    57. 57. This is better...
    58. 58. GET: /droid/r2d2 GET: /droid/c3po 404: Not the droids you’re looking for
    59. 59. HTTP/1.1 200 OK Content-Type: text/plain <?xml version="1.0" encoding="UTF-8" ?> <response code="error"> <error>Error!</error> <text>You have errored.</text> ed t o do </response> I su ppos What am this? with
    60. 60. Which leads me nicely to... RESPONSE CODES
    61. 61. IE has failed Informational
    62. 62. FTW!1 Success
    63. 63. Redirection
    64. 64. illust rating (yo u try ent er ror!) cli Client Error
    65. 65. n’t fi nd an s 1am . I ca error. It’ erver i mage for s Server Error
    66. 66. PUT: /user/MikePearce HTTP/1.1 200 OK Meh..
    67. 67. PUT: /user/MikePearce HTTP/1.1 201 CREATED Huzzah!
    68. 68. GET: /whatareyou HTTP/1.1 418
    69. 69. GET: /whatareyou HTTP/1.1 418 I’m a teapot is real1!! This one
    70. 70. Caching
    71. 71. E-Tags
    72. 72. HTTP/1.1 304 NOT MODIFIED HTTP/1.1 200 OK Date: Mon, 23 May 2005 22:38:34 GMT Last-Modified: Wed, 08 Jan 2003 23:11:55 Etag: "3f80f-1b6-3e1cb03b" Connection: close Content-Type: text/html; charset=UTF-8
    73. 73. Mmm ... Delicious!
    74. 74. NO
    75. 75. HYPERMEDIA
    76. 76. HYPERMEDIA What is it?
    77. 77. HYPERMEDIA What is it?
    79. 79. oar...
    80. 80. HATEOAS (Remember hating oars)
    81. 81. Grey Areas
    82. 82. V3r510n1ng Versioning
    83. 83. GET: /user/MikePearce in. Prolific Him aga bas tard.
    84. 84. GET: /user/MikePearce GET: /user/66
    85. 85. 1. Versioning with the URI GET: /v1/user/MikePearce GET: /v2/user/66
    86. 86. 2. Not versioning the primary URI GET: /user/66 GET: /v1/user/MikePearce
    87. 87. 3. No versioning GET: /user/66
    88. 88. Document Extensions
    89. 89. Either
    90. 90. Either GET: /reports/tpsreport/summary.json GET: /reports/tpsreport/summary.xml
    91. 91. Either GET: /reports/tpsreport/summary.json GET: /reports/tpsreport/summary.xml or
    92. 92. Either GET: /reports/tpsreport/summary.json GET: /reports/tpsreport/summary.xml or Accept: text/xml Accept: application/json
    93. 93. SUM Phew! MARY
    94. 94. Overuse of GET and POST or, GET/POST tunnelling.
    95. 95. Tunneling Errors through
    96. 96. Which leads me nicely to... RESPONSE CODES
    97. 97. E-Tags
    98. 98. NO
    99. 99. HATEOAS (Remember hating oars)
    100. 100. V3r510n1ng Versioning
    101. 101. Either GET: /reports/tpsreport/summary.json GET: /reports/tpsreport/summary.xml or Accept: text/xml Accept: application/json
    102. 102. Any qu estions? swer!) (that I can an
    103. 103. Photo Credits Wordle.net flickr.com/photos/wouterkiel/3717057757/ - Wouter Kiel flickr.com/photos/joe_13/19946186/ - joe_13 flickr.com/photos/23846880@N00/391925649/ - Rutger de Moddertukker flickr.com/photos/mararie/264942105/ - mararie flickr.com/photos/ndanger/7841795/ - ndanger flickr.com/photos/yourdon/2573762303/ - Ed Yourdon flickr.com/photos/thunderchild5/225675773/ - Thunderchild7 flickr.com/photos/duchamp/126115989/ - Duchamp flickr.com/photos/thefangmonster/490423135/ - The fang monster flickr.com/photos/nostri-imago/2894328425/ - cliff1066 flickr.com/photos/epsos/4582789354/ - epSos.de flickr.com/photos/projector/2092517108/ - allie pasquier flickr.com/photos/nickstone333/3135320160/ - nickstone333 flickr.com/photos/rdrcollection/116454033/ - Rodney Ramsey flickr.com/photos/christophercarfi/2730304130/ - Christophercarfi flickr.com/photos/turatti/4526352835/ - jaci xIII
    104. 104. Thanks! Mike Pearce mike@mikepearce.net mikepearce.net twtitter.com/mikepearce