5 ms·
Two big questions: * How do they handle deprecation? At some point, they're going to realize that their API design is wrong, could be better, or could take a
by caseysoftware 9y ago
Two big questions:
* How do they handle deprecation?
At some point, they're going to realize that their API design is wrong, could be better, or could take advantage of new patterns, methods, or even customer usage patterns. As a result, they're going to have to restructure and potentially deprecate things. Do they handle it with transparency, honesty or even just make sure your stuff still works?
At Twilio, the 2008 endpoints have been deprecated for 5+ years but still work and - to the best of my knowledge - there's no sunset announced. Yes, all the examples, docs, sdks, etc encourage you to use the new endpoints but the old ones are there. Compare that to Facebook, Google, Twitter, etc which turn on and off APIs and break things with little regard for end users. Which leads to the second question..
* What's their business model?
If they make more money as you use the platform more, that's great! In biz speak, your interests are aligned! They're going to make sure you get started as quickly as possible, minimize downtime, and make sure that your stuff works now and forever. Once again, that's the Twilio model.
If you scale from 1 to 10 to 1M requests/day and they make the same amount of money (or none in many cases), then they're going to be less concerned if you can't make 1, 5, or even 10% of those calls. Even worse, if the API itself is primarily used for market penetration purposes (once again: Twitter), they may treat you as a free R&D group and let you do the exploration and prove the market before they step in.
* Early Twilio employee, current Okta employee, wrote a book on API Design
- scarface74 9y agoSince you didn't mention your book probably because you didn't want to come off as spamming. I'll ask, what's the name of your book?
- cnj 9y agoI totally agree on the second point (business model alignment), however I believe that amount of requests does in a lot of cases not mean that your interests are aligned. Examples: * A REST API needs 3 calls for $foobar. A GraphQL API only needs 1 call. The vendor will loose money if they optimize their API in a way that you can make less calls. * Some of your data does not frequently change. If you pay per request, you can save money by caching. However, that'll make your implementation more complex (esp. if the API is supposed to be used directly from mobile apps). IMO it's better if the API provider can charge based on business metrics. E.g. Stripe charges based on payment volumne. It doesn't matter if you do 2 or 200 API calls to make a payment.
- caseysoftware 9y agoI started by saying "use the platform more" and went to API requests because that's the natural connection but you're right that the more proper phrasing should probably be "more successful with the platform"
- newlyretired 9y agoAlso relevant to this platform -- if your business is more successful when your customers are more successful, and they tell you that, and together you can measure that... you might be in a good place.
- joshribakoff 9y agoWith graphQL you have a concept of query complexity, you would base costs on complexity not number of API calls.
- fapjacks 9y agoHey that's awesome. I tell people about the Twilio API when people ask me about good APIs out there to learn from.