Your API is a UI

Chris gave a good talk on thinking about the design of APIs. He was upfront about it not involving best practices or "this is exactly how you should do it" speeches, understanding that a lot of the time there isn't one way to do it and something that would work for one client wouldn't work for another. So having it at a higher concept level, things to think about, ideas to bare in mind, etc. was good; I personally appreciated the pragmatic view of things.

On reflection, the talk has gotten me thinking (which is no doubt a good thing!) but more about nitty-gritty details... For example, Chris mentioned how they track things through their system (and showed a rather awe inspiring wall of monitors!) and I'd love to know the technical details of that; the logging mechanisms employed, the generation of metrics, how to best utilize the information to make sure your API, site, etc. are performing well (and from there how to spot the bottle necks, optimize APIs and systems, things learned from the trenches). I know this couldn't really fit in with the kind of talk that "Your API is a UI" was, so maybe an idea for a future talk?

So even though I was left questioning details of exactly how things could work, I felt that the talk really gave a good overview on things you need to consider before creating your API and that if you took all of it on board you'd end up with a pretty solid and usage API that your clients would be happy using, people could extend, and of which you might be proud.

I really enjoyed this talk. I went into it with the term "API" meaning "bog-standard REST API via HTTP", and as Chris progressed through the talk I realised this applied to not just that but also to any API you write or use - library functionality, even PHP itself to some degree. Lots to take away from this; I was definitely able to spot gotcha items that I've done badly in previous APIs, so I feel somewhat more well armed for anything in the future!