Very helpful best-practices for APIs. Definitely want to check out the book now. Most of our APIs are trivial and tightly-coupled to frontends for the same system. But we will apply these to any APIs we set up that are used more broadly.
I'm sad that we ran out of time - learned some very good things
I know you say you're never giving this talk again, but remember there's always a new audience who has never heard this information :)
I'd personally love to see some more stuff added about
versioning (more than it sucks which we all know)
swagger and other api reflection style documentation/tools
dealing with "bad actors" using apis - what are some mitigation ideas?
private versus public apis and the different considerations for both
Although I have not done any API programming, I know at one point I will be. Although at this point your presentation was a little over my head, I was able to pick out quite a few very interesting points.
You are a very skilled developer and I have considered you a hero and innovator in the PHP industry. The be able to hear you speak was amazing.
Phil really delivers on this talk, disappointed at running out of time. Very useful information that will have an impact on how I look at APIs going forward.
My team attended at least two API talks last year before starting to work on our own API in the past few months, and I was very pleased to see we have been doing it "the right way". I personally didn't get much out of this talk because it wasn't new information, but it was highly entertaining.
Phil, please slow down a little when speaking. Us Americans can't all understand you easily, and the non-americans on my team probably had an even harder time.
Engaging speaker, presented relevant information in a humourous manner. Lots of good material here, lots of little gotchas you may not otherwise consider. Especially if you're just delving into building your first APIs, this talk is very much worth attending.
"An API is literally just a way of interacting with stuff."
I loved that quote.
Reviewing my notes from this talk, everything comes across more as a practical, common-sense guide to building an API: Use a default query string, don't auto-increment values, ensure you've got unique identifiers, "Just Send JSON", don't use 200 for errors, supplement your HTTP status codes with actual human-readable content.
To date, I have limited experience working with third-party APIs, but after seeing Phil's talk and reflecting on the ones I have used, it's clear to me that there's a lot of work to be done by developers to improve the quality and consistency of their APIs. I appreciated the resources Phil provided, along with an overview of which HTTP methods to use depending on the verb.
As an aside: I attended Matt Frost's OAuth talk earlier in the day, and he and Phil seem to disagree about which version of OAuth to use.
Comments
Comments are closed.
Well that was a fun show. Tidbits of wisdom in between.
Enjoyed the talk, ran out of time, hopefully will post slides.
Very helpful best-practices for APIs. Definitely want to check out the book now. Most of our APIs are trivial and tightly-coupled to frontends for the same system. But we will apply these to any APIs we set up that are used more broadly.
Really good look at APIs without getting hung up on the "rules." Too bad he ran out of time.
Slides are up!
https://speakerdeck.com/philsturgeon/api-pain-points-lone-star-php-2015
Sorry to run out of time, the API versioning stuff can all be found here:
http://www.troyhunt.com/2014/02/your-api-versioning-is-wrong-which-is.html
Great talk, lively and energetic. Lots of good information. Sorry about not getting the time notice to you. I thought you saw me.
Excellent presentation, engaging speaker, hilarious jokes
I'm sad that we ran out of time - learned some very good things
I know you say you're never giving this talk again, but remember there's always a new audience who has never heard this information :)
I'd personally love to see some more stuff added about
versioning (more than it sucks which we all know)
swagger and other api reflection style documentation/tools
dealing with "bad actors" using apis - what are some mitigation ideas?
private versus public apis and the different considerations for both
And now... I have some apis to go fix :)
Although I have not done any API programming, I know at one point I will be. Although at this point your presentation was a little over my head, I was able to pick out quite a few very interesting points.
You are a very skilled developer and I have considered you a hero and innovator in the PHP industry. The be able to hear you speak was amazing.
Thanks for being on-point. Sorry you ran out of time. As usual Phil does not disappoint.
Phil really delivers on this talk, disappointed at running out of time. Very useful information that will have an impact on how I look at APIs going forward.
My team attended at least two API talks last year before starting to work on our own API in the past few months, and I was very pleased to see we have been doing it "the right way". I personally didn't get much out of this talk because it wasn't new information, but it was highly entertaining.
Phil, please slow down a little when speaking. Us Americans can't all understand you easily, and the non-americans on my team probably had an even harder time.
Engaging speaker, presented relevant information in a humourous manner. Lots of good material here, lots of little gotchas you may not otherwise consider. Especially if you're just delving into building your first APIs, this talk is very much worth attending.
As someone developing their first API this talk was perfect for me. Really appreciate all the information.
I hope youtube was watching.
Picked up some good knowledge. Super engaging and fun talk to attend. I'll be picking up your book to complete the cycle.
"An API is literally just a way of interacting with stuff."
I loved that quote.
Reviewing my notes from this talk, everything comes across more as a practical, common-sense guide to building an API: Use a default query string, don't auto-increment values, ensure you've got unique identifiers, "Just Send JSON", don't use 200 for errors, supplement your HTTP status codes with actual human-readable content.
To date, I have limited experience working with third-party APIs, but after seeing Phil's talk and reflecting on the ones I have used, it's clear to me that there's a lot of work to be done by developers to improve the quality and consistency of their APIs. I appreciated the resources Phil provided, along with an overview of which HTTP methods to use depending on the verb.
As an aside: I attended Matt Frost's OAuth talk earlier in the day, and he and Phil seem to disagree about which version of OAuth to use.
Excellent talk!