31–40 of 82 posts
https://code.google.com/p/google-apis-client-generator/
The service is defined in a platform-neutral discovery document, which can be used by any provider:
https://developers.google.com/discovery/v1/reference/apis
There are generators for Python, Java, .NET, Objective-C, PHP, Go, GWT, Node.js, Ruby, and others.
Earlier quoted context omitted.
I wonder how to implement that. This kind of stuff is generated from WSDLs in C#/VS, but it's an interesting idea to do it in a REST service.
Like WADL? https://en.wikipedia.org/wiki/Web_Application_Description_La... I guess I really don't get REST, shipping a REST client for a specific API is a thing. If you're gonna provide a client, who cares if it's really REST after all?
I guess REST is there to make it easier for other people to implement your API. SOAP was hard without libraries, I can hit your REST endpoint with curl.
If REST client libs didn't suck, this wouldn't be needed. It's a load of effort to correctly consume from a RESTful webservice currently. I should be able to get going in my REPL with something like: >>> from rest import client >>> proxy = client(url) >>> print proxy.resources ['foo', 'bar'] >>> help(client.foo) Help text from the rest service... >>> client.foo(123) 321 # repeat calls transparently handle caching
Relatedly, you'll want to ship first-party or "blessed" libraries for the big programming stacks as quickly as feasible. Start with the one your team uses and then roll out to the ones which are big with in your customers' industries. They're vastly easier to consume for many of your users than a standard REST API is. (Compare: Twilio::Sms.send(from, to, "This is a message.") with Httparty.post(" https://api.twilio.c…
When you're using their internal language it's often great. Any other and it's often a nightmare. For example, it's very common to see people write a bloody awful .Net wrapper that are completely non-idiomatic and a complete pita to use.
Often they're written in a way the author clearly doesn't understand OO or hasn't kept up with C# and still thinks it's just like Java so writes extremely old fashioned code. And namespaces. They want you use a million namespaces. It's a minor thing, but a completely unnecessary complication. They could stick everything in one namespace and get no conflicts.
And then, because they've put out client libraries, they don't document their API properly.
Google, as usual, are the worst offender, their .Net library is really bad and incredibly overcomplicated. It does make you wonder about all the hype of 'best' engineers.
The other problem is that they think you'll be using their API one way, when it needs to be another and their code just gets in the way, but because they don't have a snippet without using their library, you end up having to ILSpy their library and then get greeted with shockingly bad code with millions of pointless interfaces that only get used once, because, again, they don't understand .Net.
The Google APIs Client Generator is an awesome tool that automates this process. It takes a service description and generates a complete client library: https://code.google.com/p/google-apis-client-generator/ The service is defined in a platform-neutral discovery document, which can be used by any provider: https://developers.google.com/discovery/v1/reference/apis There are generators for Python, Java, .NET, Objectiv…
So we've gone full circle and arrived back at SOAP. Why didn't we just keep using SOAP in the first place?
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…
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.
Earlier quoted context omitted.
Like WADL? https://en.wikipedia.org/wiki/Web_Application_Description_La... I guess I really don't get REST, shipping a REST client for a specific API is a thing. If you're gonna provide a client, who cares if it's really REST after all?
https://pypi.python.org/pypi/wadllib/1.1.4 looks quite complicated. I'd really like to be able to do some_object.some_remote_method_call(parameters) like the parent. I guess REST is there to make it easier for other people to implement your API. SOAP was hard without libraries, I can hit your REST endpoint with curl.
I must admit that was my initial reaction when I saw the title of this article - I tend to regard curl as the universal RESTful API client. I don't think I've written or consumed a RESTful API where I didn't spend a fair amount of time interacting with the system through curl.
Earlier quoted context omitted.
Sounds like the good ol days of SOAP and WSDL
No, please. No SOAP or WSDL. over engineered.
http://en.wikipedia.org/wiki/Web_Application_Description_Lan...
The Google APIs Client Generator is an awesome tool that automates this process. It takes a service description and generates a complete client library: https://code.google.com/p/google-apis-client-generator/ The service is defined in a platform-neutral discovery document, which can be used by any provider: https://developers.google.com/discovery/v1/reference/apis There are generators for Python, Java, .NET, Objectiv…
> The Google APIs Client Generator is an awesome tool that automates this process. It takes a service description and generates a complete client library So we've gone full circle and arrived back at SOAP. Why didn't we just keep using SOAP in the first place?
If REST client libs didn't suck, this wouldn't be needed. It's a load of effort to correctly consume from a RESTful webservice currently. I should be able to get going in my REPL with something like: >>> from rest import client >>> proxy = client(url) >>> print proxy.resources ['foo', 'bar'] >>> help(client.foo) Help text from the rest service... >>> client.foo(123) 321 # repeat calls transparently handle caching
>>> from hammock import Hammock as Github
>>> # Let's create the first chain of hammock using base api url
>>> github = Github('https://api.github.com')
>>> # Ok, let the magic happens, ask github for hammock watchers
>>> resp = github.repos('kadirpekel', 'hammock').watchers.GET()
>>> # now you're ready to take a rest for the rest the of code :)
>>> for watcher in resp.json: print watcher.get('login')
kadirpekel
...
..