Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Writing REST API Clients

ttezel.github.com

Post reply on HN
Print view View original

51–60 of 137 posts

Re: Stop Writing REST API Clients

#51

Post by algorithmmonkey »

michaelw wrote: post #14

Sigh. This is optimizing for the wrong problem. Stop creating REST APIs that are only level 1 or 2 (see http://martinfowler.com/articles/richardsonMaturityModel.htm... ). Start writing HATEOS systems where the client is coupled to the semantic rather than the syntax. Machine parseable interface descriptions might get rid of some boilerplate but it doesn't make for a more robust client-server relationship.

true story. we could do worse than moving toward something like: http://stateless.co/hal_specification.html.

Re: Stop Writing REST API Clients

#53

Post by mtts »

stan_rogers wrote: post #41
eintr wrote: post #26

Yeah, let's do CORBA once again. No thanks.

Well, it wouldn't be so bad if it were universal enough, but we'd probably have to wrap it in some sort of inter-ORB protocol for the internet or something...

Yes it would. Because making it universal enough makes it incredibly verbose and nasty to work with. JSON became popular because it was simpler than Web Services which became popular because it was simpler than CORBA which became popular because it was simpler than just talking over raw sockets using some sort of protocol ... oh, wait.

Actually not having a "universal" spec helps: it forces every provider to give some thought to how to make his API as lean as possible. Hopefully.

Re: Stop Writing REST API Clients

#55

Post by steveklabnik »

tommorris wrote: post #8

Substitute "XML" for "JSON" and we've now come full circle. The point about REST is that it is self-describing. And ideally should be using the same URIs as the version people clicking around in Firefox or Chrome see. The API is just the XML or JSON or whatever is flavour of the week version of the HTML version. (Or we could use embedded data—microformats, microdata, RDFa—and get rid of that distinction.)

Yes, we have. http://en.wikipedia.org/wiki/Web_Application_Description_Lan...

Re: Stop Writing REST API Clients

#56

Post by ahallock »

While I understand the allure of writing specs and using a unified library, good API clients are more terse, as they're written to take advantage of the programming language you're using, and understand the particulars and idioms of the API they're written against. For example, the client might pick up the correct environment variables for your API credentials, or reduce certain repetitive code.

Another example: I wrote a client that returns a queue message. Attached to that message are some helper methods for deleting, releasing, and touching the message. It makes your code cleaner and easier to understand.

Re: Stop Writing REST API Clients

#57

Post by steveklabnik »

michaelw wrote: post #14

Sigh. This is optimizing for the wrong problem. Stop creating REST APIs that are only level 1 or 2 (see http://martinfowler.com/articles/richardsonMaturityModel.htm... ). Start writing HATEOS systems where the client is coupled to the semantic rather than the syntax. Machine parseable interface descriptions might get rid of some boilerplate but it doesn't make for a more robust client-server relationship.

As one of my friends on twitter said, "Yes, people won't put their URIs in responses, so let's just put them in this other, totally unrelated file."

Re: Stop Writing REST API Clients

#58

Post by stephen »

petercooper wrote: post #18

We could give a name to the language we use to define such files. It's a language that defines Web services, so perhaps Web Services Description Language? :-) http://en.wikipedia.org/wiki/Web_Services_Description_Langua... Flippancy aside, maybe there's a need for a next generation of this that skips all the XML headaches after all.

The problem wasn't XML itself, but the complexity they tried to encode in XML. The same sins could be committed in JSON.

JSON has just been lucky that its user base hasn't been the same enterprise architects that ruined Java.

Post reply on HN