31–40 of 76 posts
Wouldn't it be wiser to choose a hypermedia format for the API, and then use a generic hypermedia client on whichever platform you like? Then you write just as many client libraries (zero), but the problem of pushing updates to your clients is solved as well. Full disclosure: I wrote such a library for Ruby, called HyperResource. https://github.com/gamache/hyperresource
Damn, HyperResource looks sexy.
Wouldn't it be wiser to choose a hypermedia format for the API, and then use a generic hypermedia client on whichever platform you like? Then you write just as many client libraries (zero), but the problem of pushing updates to your clients is solved as well. Full disclosure: I wrote such a library for Ruby, called HyperResource. https://github.com/gamache/hyperresource
I agree its nice to do it that way. But I found that not all APIs use hypermedia format. So, I did it this way. :)
Neat tool!
Earlier quoted context omitted.
How do you differ from Swagger, Blueprint, I/O Docs, RAML and all these API endpoint descriptions?
I tried searching for a program which generates client libraries in different programming languages and failed. 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
Wouldn't it be wiser to choose a hypermedia format for the API, and then use a generic hypermedia client on whichever platform you like? Then you write just as many client libraries (zero), but the problem of pushing updates to your clients is solved as well. Full disclosure: I wrote such a library for Ruby, called HyperResource. https://github.com/gamache/hyperresource
At risk of writing a vacuous comment but as a supporter of more HN positivity... Damn, HyperResource looks sexy.
Just tried this out and Alpaca is an awesome tool. However, I'd never want to release this in production without tests. Alpaca doesn't generate tests, so you're back to maintaining the tests for your N different platforms/languages. But you'd have the same problem with its competitors, too; Thrift [0], for instance, doesn't generate tests either. Overall, I'm not sure that the time savings is as big as it first appea…
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?
Author here. I covered almost everything in the documentation. And there is also a small example which is hosted at https://github.com/alpaca-api . Please ask if you have any questions. Thanks
Wouldn't it be wiser to choose a hypermedia format for the API, and then use a generic hypermedia client on whichever platform you like? Then you write just as many client libraries (zero), but the problem of pushing updates to your clients is solved as well. 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.
Author here. I covered almost everything in the documentation. And there is also a small example which is hosted at https://github.com/alpaca-api . Please ask if you have any questions. Thanks
Hey, I noticed you mentioned that you were interested in having client library generation in Obj-C, Java, and Scala, yet all of the existing client lib support is for dynamic languages. I think you may find that some fundamental changes need to be made to support this, unless every datatype is just going to be a string.
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?
Regarding bug reports: > Guaranteed reply within a day. That seems difficult to achieve--wonder how they're doing that? (Also, why??)
I am just a single guy. I always make a point to reply back to issues/pull-requests on my open source projects within 24hrs. Yes, sometimes I fail to make it. But it's a rule I want to live by.