N.B. Pipelining can be used for any idempotent request (so PUTs and DELETEs work too). That said, lack of broad implementation support for pipelining is still an issue. Since HTTP/2.0 is being based on SPDY, hopefully we'll see a day where this is less of an issue.
I'm pretty sure Google's home page doesn't include every possible search term for you to select from, and that's a perfectly RESTful example of an exposed function (search). Forms are a very powerful hypermedia construct.
In the context of a website, maybe you can have a helper like that to avoid the REST bloat. But the architecture is for arbitrary APIs, existing outside of web pages, in which I don't have a neatly visible form. All I'm allowed to do is give the user URIs to choose from.
Some kinds of apps (esp those that can't tolerate the overhead of REST, like for mobile) need to know how to format a Google search request without navigating through a session on Google site, but just knowing what it should look like, and formatting it that way. REST would restrict you to pointing them to google.com and following links; it prohibits you from saying, "hey, you can have your app just point to google.com, then '?q=', then your search terms connected by +'s".
Yep! Works like a charm, until you have to expose a URI pointing to every combination of cities (or indeed, combination of any parameter set).
And I know (like I said before) you can fall back on "no, just tell the user where to put the parameters and you won't have to do that!" ... which is just re-inventing the RPC -- and satisfying users that don't want to navigate a long session just to find the URI they want, every time they send a request.
>Also, while POST can mean "create", it can also mean "append" or "process some arbitrary request."
Used correctly, it doesn't mean (that the sender is requesting that you) "process some arbitrary request"; it should only be used for non-idempotent operations. Close enough to summarize as "create" (appending is certainly creating something in this context!), and generally, for something to have different effects when repeated, you have to create something. PUT/update and DELETE/delete are idempotent specifically because the changes they make aren't creations.
In any case it's clearly an abuse of the term "very different concept from" in the GGP's comment "And POST/GET/PUT/DELETE is a very different concept from CRUD".
I think it's somewhat of a benefit to make the clients expect to do a little searching to find the data/links/forms they want to use--it makes them a little more robust and adaptable (I guess because they have lowered expectations!). Contrast this to a client dependent on an XML or JSON Schema. Yeah, that client is easy to write, but you've now locked the server into not changing its format or you've doomed the client to break when the server decides to change anyway. I'm shooting for something a little better.
You can't totally decouple the clients; they have to understand in some way the vocabulary the server is using, but you can do a lot to decouple them from the structure of the markup.
Yep, this is really the point. If we think hypermedia APIs give you evolvability, then we've got to figure out how to do it; we don't have libraries for that sitting around, so someone has to do some work somewhere.
HAL is going for "start with something clean for machines (JSON and XML), layer in hypermedia, get people to adopt it." This seems like a perfectly reasonable approach.
I'm suggesting another approach, which is "start with something that supports hypermedia and is already ubiquitous on the web, and figure out how to get machines to make sense of it."
I'm not sure either one is easy, so it's worth having multiple horses in the race, I think.
