Full disclosure: I wrote such a library for Ruby, called HyperResource. https://github.com/gamache/hyperresource
Is there such a generic Hypermedia client for Python?
How does this affects performance? Navigating through the maze of a Hypermedia API requires many more requests than just hitting a known endpoint, doesn't it? Do hypermedia clients provide client-side caching?
My other concern is that those APIs might be harder to learn than ad hoc fiat standard. The reason why RESTful-ish APIs have been successful is because they don't add any overhead on top of the things they're representing. At first glance, stuff like JSON-LD, Siren, HAL, etc. seem to be bringing back the complexity of things like SOAP that people have fled from.
One of the things I like most about hypermedia is that the hyperlinks can represent a complete set of functions which can be applied to an object. In other words, each object contains its own method list. This fits well in languages which get to implement catch-all methods, like Ruby, and I couldn't resist coding up a client that worked that way.
(There's room for this sort of trickery in near-future ECMAScript too, with Proxy[3]. I would really like someone to do this and I would kind of like it to not be me.)
When you lay out your API according to that philosophy, and cache a few "stepping-stone" objects you'll be traversing often, hypermedia APIs don't seem so inefficient at all.
As to your last point: take a look at HAL[4]. It sits alongside a "traditional" API layout very nicely, essentially adding "_links" and "_embedded" which can be safely ignored by non-hypermedia clients. The HAL spec is extremely sane.
[1] https://github.com/codegram/hyperclient
[2] http://weluse.github.io/hyperagent/
[3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> Python?
There are some libraries, expect more to spring up soon.
> How does this affect performance?
This kind of question is incredibly broad. In ways it's more efficient, in ways it's less. It Depends.
That said, as you alluded to, caching should be very prevalent, so that helps.
Also, it's not like you have to make 5 requests any time you want to do anything: the point is that you follow the application's state along. Just one request per transition. A maze is a pretty decent analogy, actually...
> harder to learn than an ad hoc fiat standard
They may _seem_ harder to learn, but you have to re-learn every single ad-hoc standard over and over and over and over. If you learn HAL, you can speak to any number of APIs that use HAL. Plus, you say 'complexity,' I say, 'no surprises.' Everything is actually enumerated for you, so it should be easier to learn. No hidden assumptions.
Furthermore, as you're more familiar with the format, the details fade into the background. I'm sure you don't read RFC 4627 every time you want to deal with a JSON-based API, either.
Neat tool!
Please ask if you have any questions. Thanks
Could you please link if something does it? From what I gather, the above mentioned sites only provide methods of describing the API and/or Automating the API on the server side. Nothing is said about client libraries.
Thanks
If you are talking about the code of the program, they wont be changed because, the program just compiles and executes the templates.
If I didnt answer your question properly, could you please elaborate?
Overall, I'm not sure that the time savings is as big as it first appears, but I think it's great for quick projects.
This current program just a small step in the right direction. :)
EDIT: Currently, I have a test suite at https://github.com/pksunkara/alpaca/tree/testing which tests the generated client libraries of an example API with the respective server.
A bunch of passing tests shouldn't make you feel comfortable able releasing something to production. Proper code review and monitoring of client failures on your servers should make you confident.
My thinking is that, if trusted to output a library that matches the API spec, there is no need to test that API. However, that does require that Alpaca is well-tested enough to be trusted - would you be happy with tests in Alpaca itself, or should it generate tests too?
SPORE already has clients for Clojure, Javascript, Lua, NodeJS, Perl, Python, and Ruby. I have used SPORE in a few projects and I was not disappointed. Another approach to solving the cross language library problem.
There is also an RFC for "JSON Hyper Schema" which is intended to describe REST APIs. It doesn't have much library support in much of everything, but I am surprised that it hasn't taken off!
I like that this library is fairly opinionated (options for how to authenticate, supported formats, etc.) Though I worry that that creates a bit of inflexibility - for what exactly does "oauth" actually mean, there are always vagaries.
Neato!
But, to do that I need a format using which people can define their API. I used JSON and only supported the elements that I needed to generate the client libraries.
I wonder if we'll see JSON versions of DISCO and whatnot as well.
Having said that, this tool does look interesting. I hope that a goal is to always make sure that the generated code is as readable, and maintainable, as possible. Also, as mentioned by others, adding generated tests to the generated client libraries is extremely important.
I tried to make them a lot more readable. :)
Edit : If you don't make oauth consumption simpler, you don't really solve the problem
These will cover most of the APIs. And I am open to include other kind of authentication strategies too.
https://github.com/pksunkara/alpaca#authorization-strategies
EDIT: OAUTH Consumption is not the main priority here. The problem I intended to solve is automating the development and maintaing of API client libraries in several different languages.
That said, I intend to add support for OAUTH consumption too.
This is actually pretty similar to a side project I've been working on called Gargl (Generic API Recorder and Generator Lite) (https://github.com/jodoglevy/gargl). Haven't gotten around to doing a Show HN post yet, but would love any feedback or to combine efforts. Basically it lets you generate an API for websites that don't have APIs publically available, by looking at how a web page / form submission of that web site interacts with the web server. You record web requests you make while normally browsing a website via a chrome extension, parameterize them as needed, and then output your "API" to a template file. Then this template file can be converted to a client library in a programming language of your choosing.
$PayPal = new SoapClient($WSDLLocation); $PayPal->SomeMethod();
Yes, you can get away with having a less verbose description language if your needs are simpler, but that to me just ends up moving the problem when your needs become less simple. It's not like you can avoid validating your requests in some way, and required/not required is where that starts -- but, I maintain, not sufficient. I most definitely fail to see client code generation as being a necessary step.
You could say I've made this mistake myself; the thought process that leads to code like this must not be unique. Web services need documentation if they are to be used, and since that code will only ever talk to other code, it makes sense to have a machine-parseable description. Language agnosticism follows as a matter of course. I'm willing to entertain that XML was a bad idea and JSON Schema is not an improvement, but I still feel that if one must reinvent the concept of a language-agnostic machine-parseable web services description language, one should thoroughly understand the prior art. It may be complex for a reason, and like it or not all that SOAP stuff actually tends to work pretty well. I'm sure I have every reason for wanting to see a better technology suite which is JSON based, and I wish this were it. At the moment I don't think you're headed in quite the right direction.
> Guaranteed reply within a day.
That seems difficult to achieve--wonder how they're doing that? (Also, why??)
Yes, sometimes I fail to make it. But it's a rule I want to live by.
Done.
Know what I think would be really neat? If it could be pointed at an instance of Swagger-UI, or use the same discoverUrl that Swagger-UI would use, and spit out the libraries from that.
If you're not familiar.. https://github.com/wordnik/swagger-ui
It lacks documentation, a bunch of features, and parts smell pretty bad, but since the topic came up I thought maybe someone would find it interesting, if only vaguely.
Java, Node, PHP, Python, Objective-C, Ruby, and .NET
It looks like alpaca supports:
Java, Go, Perl, Clojure, Scala, Obj-C
