Your REST API should come with a client

Re:Your REST API should come with a client by johns on Monday April 28, 2014 @02:29AM (#7658506)

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 and we've talked about this many times on trafficandweather.io if you want to learn more.

[ Parent | on HN ]

Re:Your REST API should come with a client by MichaelGG on Monday April 28, 2014 @03:51AM (#7658730)

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.

[ Parent | on HN ]

Re:Your REST API should come with a client by cordite on Monday April 28, 2014 @05:48AM (#7659006)

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.

[ Parent | on HN ]

Re:Your REST API should come with a client by darrelmiller on Monday April 28, 2014 @08:10PM (#7664001)

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/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/...

[ Parent | on HN ]

Re:Your REST API should come with a client by Flenser on Wednesday April 30, 2014 @06:18AM (#7672443)

Enjoyed the presentation, a link to the slides[0] would have saved some googling

Is this: https://github.com/hannestyden/hyperspec the HyperSpec you refer to?

[0]: https://speakerdeck.com/johnsheehan/building-api-integration...

[ Parent | on HN ]

Re:Your REST API should come with a client by voltagex_ on Monday April 28, 2014 @04:26AM (#7658826)

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.

[ Parent | on HN ]

Re:Your REST API should come with a client by johns on Monday April 28, 2014 @12:54PM (#7661170)

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

[ Parent | on HN ]

Re:Your REST API should come with a client by cdelsolar on Tuesday April 29, 2014 @01:27AM (#7665140)

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.

[ Parent | on HN ]