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

131–137 of 137 posts

Re: Stop Writing REST API Clients

#131

Post by steveklabnik »

stephen wrote: post #129
steveklabnik wrote: post #96

Earlier quoted context omitted.

You're forgetting form-style affordance. For example, if you were using HTML as your media type, the equivalent of the first example would be > AFAIK you're still going to want some marshaling to/from host language. Actually, you explicitly _don't_ want this. That's what hypermedia APIs are trying to remove.

We're replying to each other in separate comment threads :-), but this input form is still coupling--you can't add/remove/change the access_tokens/fields without clients breaking. Humans can handle that. Software can't. That's why I think hypermedia makes all sorts of sense for explaining why the www is awesome--it change deal, users will adapt. But IMO it falls flat as some new paradigm for building client/server sy…

Haha! Ping-pong!

> But IMO it falls flat as some new paradigm for building client/server systems.

I know of one company which you've absolutely heard of who has a 30-person team building a hypermedia API. They haven't talked about it publicly because they see it as a strategic advantage.

This year will be the year of code and examples; last time I was in San Fransisco, 5 different startups came up to me and told me that hypermedia is solving their problems. Expect to see more of this going on soon.

> Hm? I am skeptical...any links/explanations?

Mike Amundsen's "Building Hypermedia APIs in HTML5 and Node" has a pretty big section on this, and my book has a section entitled "APIs should expose workflows."

I previously commented more about it here: http://news.ycombinator.com/item?id=4951477

RPC APIs expose functions, SOAP/"REST" APIs expose objects, hypermedia APIs expose processes.

Re: Stop Writing REST API Clients

#132

Post by manishsharan »

user24 wrote: post #108
manishsharan wrote: post #91

I want to give you an idea of how bad things are with REST Api Client . This is a Maven POM for Google APIs for java web project that uses Google APIs for Profile, Drive and Oauth2. Its insane: 4.0.0 com.google google 5 com.google.api.client google-plus-java-webapp-starter war 1.0.0 google-plus-java-webapp-starter Web application example for the Google+ platform using JSON and OAuth 2 https://code.google.com/p/google…

Can you stick that in a gist[1] so as to not mess up the HN comments? [1] https://gist.github.com/

I realize now that cut-paste from my code into comment was a bad idea ; I wish I could edit this post -- but i am unable to do ( no edit link). Lesson learnt for next time.

Re: Stop Writing REST API Clients

#133

Post by Flenser »

stephen wrote: post #68
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.

Yes, URIs in the response sounds amazingly cool, but it won't change anything. The inline URLs of the web work because the consumers are humans who can deal with changes (more than just trivial URL changes, like added, removed features) and now click on this button or that button. Software isn't that flexible, so it will be just as coupled as it is today--you're just moving the coupling around. So this idea of a "rob…

With some conventions how the api is structured it's possible to have loose coupling the between client and server. This video demonstrates how it is possible to make changes in structure of the API that the client detects automatically:

http://oredev.org/2010/sessions/hypermedia-apis

And he's release a Java library for creating such a client:

https://github.com/cimlabs/hypermedia-client-java

Re: Stop Writing REST API Clients

#134

Post by bpphillips »

ttezel wrote: post #64
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 my argument is simply that we publish API specs in a machine-readable format to avoid wasting time implementing clients repeatedly. WSDL and WADL had good intentions at heart, but XML is ugly. JSON is nice since it's human-readable and light. Why not publish JSON versions openly for REST APIs, reducing implementation cost for clients?

This seems similar in goal to the SPORE project (https://github.com/SPORE). Have you seen that and/or considered merging efforts?

Re: Stop Writing REST API Clients

#136

Post by mindcrime »

dsego wrote: post #109
mindcrime wrote: post #87

Earlier quoted context omitted.

XML is more human readable than JSON, to my eyes.

Really? Let's write a shopping list on a piece of paper in JSON and XML. Which one would be more similar to the way we write down lists in real life?

Really? Let's write a shopping list on a piece of paper in JSON and XML. Which one would be more similar to the way we write down lists in real life?

XML:

   
     
       Milk
       Eggs
       Bread
       Butter
JSON:

    {
       "list": {
         "items": [
            "Milk",
            "Eggs",
            "Bread",
            "Butter"
        ]
      }
    }
I don't know that either one is particularly close to the way I'd write down a list in real life, to be honest. This is a pretty trivial sample, and neither is especially hard to read/parse by a human. But the JSON still looks closer to line-noise to me. :-)

Re: Stop Writing REST API Clients

#137

Post by ubermammal »

TelmoMenezes wrote: post #24

Am I the only one who doesn't like receiving direct orders from article titles?

You aren't, but it's a mistaken thing to dislike: there's no value to rephrasing it as "I believe you should [do X]" or "I am arguing that you should [do X]" because that's necessarily always true anyway, i.e. no article can ever be anything other than what the author believes and argues for. So 'softening' the language would be inefficient - it would use more words while adding nothing of substance.
Post reply on HN