A client template library for REST API need to be Turing complete, otherwise it will be too weak to be able to handle complex services or complex client-side tasks, such as caching, dependency relations, data that span multiple services etc. Even if you make the template library simple, you'll need to wrap that with a layer of complex code. All you've done will be adding another layer on your code. You could re-design your code to fit a manageable design, but server side of the REST APIs are usually design by others whose priority is the code on the server side. So, by definition of the very task, the REST API client code have to be a complex soup where the client considerations mix up with those of the servers'.
Stop Writing REST API Clients
101–110 of 137 posts
Re: Stop Writing REST API Clients
#102I 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…
What would you remove? How could it be simpler? I don't mean how could it be less verbose, but how could you describe those various project attributes in a way that wouldn't lead you to another markup language with the same data?
I am getting rid of all Google api jars. Google has a well documented REST API for OAuth 2.0 and drive ; I am refactoring my code to only use standard commons http client jars along with java JSON (e.g. jackson )jars and invoke standard REST api.
Re: Stop Writing REST API Clients
#103Isn't this what http://json-schema.org aims to provide? Or am I missing something. It's a solid spec.
Personally I'm partial to http://jschema.org/ (also see http://jschema.org/rpc.html ) because it seems simpler. My naive impression is that JSON-Schema is trying to be just like XML Schema, but in JSON. Which doesn't seem like a good thing.
But neither of these are geared towards a RESTful implementation, unless I'm missing something.
Re: Stop Writing REST API Clients
#104Earlier quoted context omitted.
What would you remove? How could it be simpler? I don't mean how could it be less verbose, but how could you describe those various project attributes in a way that wouldn't lead you to another markup language with the same data?
I am getting rid of all Google api jars. Google has a well documented REST API for OAuth 2.0 and drive ; I am refactoring my code to only use standard commons http client jars along with java JSON (e.g. jackson )jars and invoke standard REST api.
Is there a public repo where I could follow your progress? My interest is piqued.
Re: Stop Writing REST API Clients
#105Earlier quoted context omitted.
What would you remove? How could it be simpler? I don't mean how could it be less verbose, but how could you describe those various project attributes in a way that wouldn't lead you to another markup language with the same data?
I am getting rid of all Google api jars. Google has a well documented REST API for OAuth 2.0 and drive ; I am refactoring my code to only use standard commons http client jars along with java JSON (e.g. jackson )jars and invoke standard REST api.
[deleted]
Re: Stop Writing REST API Clients
#106Earlier quoted context omitted.
I am getting rid of all Google api jars. Google has a well documented REST API for OAuth 2.0 and drive ; I am refactoring my code to only use standard commons http client jars along with java JSON (e.g. jackson )jars and invoke standard REST api.
Is there a public repo where I could follow your progress? My interest is piqued.
Thats a great idea. I haven't set up my github profile yet -- this may very well be the project to start with.
Re: Stop Writing REST API Clients
#107Sigh. 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.
Can you give an example of an acceptable implementation of a HATEOAS REST API (wow, that's a lot of letters) with an associated client that actually uses it? My experience has been that you can't communicate much through HATEOAS that's actually beneficial to a human programmer writing a client. Sure, you can add all the hypermedia links you want in your API responses, but how does that make writing a client easier? W…
> (wow, that's a lot of letters)
We're all calling these "hypermedia APIs" these days.
> with an associated client that actually uses it?
I have written a toy client here: https://gist.github.com/steveklabnik/2187514
You can run it against this site, written in node: http://alps-microblog.herokuapp.com/
Or this site, written in Rails: https://rstat.us/
It (should, I haven't tried it in a long while) work with both just fine. They both use the ALPS microblogging spec. yay generic clients!
As for people who have 'more real' ones: GitHub, Twilio (partially, more in the future), Balanced Payments (YC W11, iirc), Comcast (though that's internal :() Netflix has aspects, FoxyCart.
This year will be the year of examples.
Re: Stop Writing REST API Clients
#108I 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?
Re: Stop Writing REST API Clients
#109Earlier quoted context omitted.
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?
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?
Re: Stop Writing REST API Clients
#110This article is not at all about REST, it is about RPC and its shortcomings. These shortcoming were fixed by REST, and the author of the article rediscovers these fixes. A key features of a REST API is that is self describable, in a sense, that it has a single entry point from which a generic client can automatically discover available resources and actions. APIs in the given examples are not like this, they require…
> A key features of a REST API is that is self describable How practical is that, in reality? I know I've added the whole HATEOAS thing to my API and I am not sure if it just makes my IDs longer. Customers seem to hard-code the API entry points anyway. Everyone of course says "Oh, yeah this is cool" but when it comes to doing it given performance constraints, they don't want to start generating 10s of extra GET reque…
It of course depends on the problem, no architecture is good for everything. REST has its cost, it usually requires more work and careful design then going RPC way, but for some kind of problems it can be really beneficial when done right.
Imagine you have a company that does custom mobile apps for external customers. A very popular topic, a lot of companies today want to have their own apps in addition to standard web pages.
Most of these apps are very similar (you can browse come content, purchase some service, etc.). Your company can go RPC way and create a custom interface and a custom client for each customer, with a lot of duplication and substantial maintenance cost. Or your can make larger upfront investment and create a generic REST client and then only design resources and representations for each new customer.