3 ms·

Providers should definitely provide clients. This is one of the things I worked on at Twilio and it's extremely important for onboarding new customers. Support

by johns 12y ago

Providers should definitely provide clients. This is one of the things I worked on at Twilio and it's extremely important for onboarding new customers. Support as many languages and frameworks as you can sustain and make them first-class (just as well documented as REST, native to the language, etc). However, I've also seen the other side of this working at IFTTT where (at the time) we had a gemfile a mile long. That got really hairy. I now try to avoid using clients. I go into it in great detail here: https://www.youtube.com/watch?v=dBO62A3XaSs https://www.youtube.com/watch?v=dBO62A3XaSs and we've talked about this many times on trafficandweather.io if you want to learn more.

MichaelGG 12y ago
Is Twilio really rest? Versioning and formatting info in URLs isn't REST-like. Plus the docs suggest you construct URLs, which isn't RESTful. I love Twilio's API, I just don't understand the REST part. I fail to see how "PATCH /accounts/123/ <postbody>" is better than "POST /accounts/updateaccount <postbody accountid=123 ...>", especially when hidden behind a lovely client.
- cordite 12y ago
  It seems they try to provide a somewhat hypermedia oriented API. What I really don't like is they don't accept my accept headers, and I have to change the extension on the end. Going to /.json feels like ilk to me.
  - darrelmiller 12y ago
    For some additional insight on accept based conneg. The guys who created it, really wish they hadn't. http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html http://www.alvestrand.no/pipermail/ietf-types/2006-April/001... "Regarding proactive negotiation in HTTP/2, I'll note that Waka strips all negotiation fields. I find the entire feature revolting, from every architectural perspective, and would take the opportunity of 2.x to remove it entirely." Roy Fielding http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0286.html http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/...
voltagex_ 12y ago
I just watched the talk. It's really interesting and raises a few things I haven't thought about before. Do you have any more information about automatic service/endpoint discovery and also about the smart HTTP client you use? I would have thought that failing over to another endpoint address would have been done at a load balancer level.
- johns 12y ago
  I can't recall the exact episode, but we talked more about smart client on trafficandweather.io We definitely need to publish more about it
cdelsolar 12y ago
At Leftronic we've also started to avoid clients. When you connect to many APIs you start running into issues with poorly supported clients and mile-long pip freezes. We like providing our own clients to our API because it's a nice quick way to get started but I think nothing beats good old python-requests and reading API docs.
Flenser 12y ago
Enjoyed the presentation, a link to the slides[0] would have saved some googling Is this: https://github.com/hannestyden/hyperspec https://github.com/hannestyden/hyperspec the HyperSpec you refer to? [0]: https://speakerdeck.com/johnsheehan/building-api-integrations-you-can-live-with https://speakerdeck.com/johnsheehan/building-api-integration...

by johns 12y ago

MichaelGG 12y ago

Is Twilio really rest? Versioning and formatting info in URLs isn't REST-like. Plus the docs suggest you construct URLs, which isn't RESTful. I love Twilio's API, I just don't understand the REST part. I fail to see how "PATCH /accounts/123/ <postbody>" is better than "POST /accounts/updateaccount <postbody accountid=123 ...>", especially when hidden behind a lovely client.

cordite 12y ago
It seems they try to provide a somewhat hypermedia oriented API. What I really don't like is they don't accept my accept headers, and I have to change the extension on the end. Going to /.json feels like ilk to me.
- darrelmiller 12y ago
  For some additional insight on accept based conneg. The guys who created it, really wish they hadn't. http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html http://www.alvestrand.no/pipermail/ietf-types/2006-April/001... "Regarding proactive negotiation in HTTP/2, I'll note that Waka strips all negotiation fields. I find the entire feature revolting, from every architectural perspective, and would take the opportunity of 2.x to remove it entirely." Roy Fielding http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0286.html http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/...

voltagex_ 12y ago

I just watched the talk. It's really interesting and raises a few things I haven't thought about before. Do you have any more information about automatic service/endpoint discovery and also about the smart HTTP client you use? I would have thought that failing over to another endpoint address would have been done at a load balancer level.

johns 12y ago
I can't recall the exact episode, but we talked more about smart client on trafficandweather.io We definitely need to publish more about it

cdelsolar 12y ago

At Leftronic we've also started to avoid clients. When you connect to many APIs you start running into issues with poorly supported clients and mile-long pip freezes. We like providing our own clients to our API because it's a nice quick way to get started but I think nothing beats good old python-requests and reading API docs.

Flenser 12y ago

Enjoyed the presentation, a link to the slides[0] would have saved some googling Is this: https://github.com/hannestyden/hyperspec https://github.com/hannestyden/hyperspec the HyperSpec you refer to? [0]: https://speakerdeck.com/johnsheehan/building-api-integrations-you-can-live-with https://speakerdeck.com/johnsheehan/building-api-integration...