121–130 of 137 posts
Earlier 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.
IMHO, what's needed is better support for "generic" REST in programming languages and/or libraries. Objective-Smalltalk (http://objective.st) features "Polymorphic Identifiers", which make it possible to both interact directly and abstract over web interfaces.
To reference a URL, just write it down:
news := http://news.ycombinator.com
#!/usr/local/bin/stsh
#-zip:zipCode
ref:http://zip.elevenbasetwo.com getWithArgs zip:zipCode
#!/usr/local/bin/stsh
#-scurl:urlref
fileComponent := urlref url path lastPathComponent.
file:{fileComponent} := urlref value.
scheme:rfc := ref:http://datatracker.ietf.org/doc asScheme
Earlier quoted context omitted.
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 ju…
Earlier quoted context omitted.
> (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 ju…
Interesting. I didn't realize that there were specs like ALPS for defining how to implement this kind of thing. Isn't it still a little difficult to do this for APIs that don't neatly fit into some kind of generic profile (e.g. microblogging)?
Mike Amundsen's terribly named but amazingly well written 'Building Hypermedia APIs in HTML5 and Node' is a really thorough examination of this topic.
Earlier quoted context omitted.
Thank you for being realistic. REST means more than just GET, POST, PUT, DELETE. Some may make the excuse that call OPTIONS /path isn't straightforward, but I have no clue how you could get more obvious than that.
The problem with OPTIONS is it doesn't describe anything about the data the resource returns. I really wish there was a DESCRIBE verb that would return a structure of what is expected to be received/sent. Then microformats could spring up around datatypes returned by DESCRIBE. This is of course very XML. Edit: This would also allow for automatic discovery of new APIs.
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…
Both are currently used by Google's public APIs to auto-generate clients. Ruby/Python clients load the schema docs at runtime and do method_missing magic, Java/.NET clients generate static typed libraries periodically.
Earlier quoted context omitted.
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…
I've built these kinds of things before: http://words.steveklabnik.com/i-invented-hypermedia-apis-by-...
http://example.com/low.rss rel="podcast_url" />
You've moved the coupling from "look at URL xyz" to "look for rel podcast_url". Okay, yes, you can now change the URL, that's cool, but I assert that's relatively trivial. You can't truly add/remove new functionality (or break existing contracts, like "look for rel=podcast_url") that some omnipotent client would suddenly start taking advantage of.
IMO this omnipotent realization/utilization of new/changed features is what hypermedia advocates get all excited about, without realizing that humans are really the only ones that can deal with that level of (true) decoupling.
Earlier quoted context omitted.
Really? Seems to me like Hypermedia APIs should move the problem from the wire protocol to the application protocol? Hypermedia says "oh yeah, here's some markup, look there are URIs in it". For a human user, we're like "cool, I'll try and click these, see what they do". But software is going to want "um...okay, how to I parse this markup, and how do I generate the submissions you want? And, okay, you can change URIs…
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.
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 systems.
> Actually, you explicitly _don't_ want this. That's what hypermedia APIs are trying to remove.
Hm? I am skeptical...any links/explanations?
Earlier quoted context omitted.
I've built these kinds of things before: http://words.steveklabnik.com/i-invented-hypermedia-apis-by-...
Not saying that system doesn't sound cool, but my point about hypermedia APIs is that when you serve back: http://example.com/low.rss rel="podcast_url" /> You've moved the coupling from "look at URL xyz" to "look for rel podcast_url". Okay, yes, you can now change the URL, that's cool, but I assert that's relatively trivial. You can't truly add/remove new functionality (or break existing contracts, like "look for rel…
> You can't truly add/remove new functionality
You can absolutely add new functionality, because rule #1 of clients that work this way is 'ignore things you don't understand.' Removal will obviously break things, so it's important to handle this in the appropriate way.
I guess ultimately my point is that these kinds of APIs are significantly different, and come with a very different set of constraints/goals/implementation details. It's like you're saying "well, I don't have a full list of function calls I can make!" because you're used to SOAP where there's a WSDL and 'RESTful' APIs don't have description documents. Of course! It's a different architecture!