When REST isn't Good Enough • Hacker News Board

Re: When REST isn't Good Enough

#91

Post by jon_moore » Wed, Nov 28, 2012, 3:02 AM UTC

SilasX wrote: post #84

bct wrote: post #65

Earlier quoted context omitted.

> what resource is it acting on? The distance between the two cities. > You have to come up with some added, unnecessary, implementation-exposing abstraction like "CityPair". This is a really weird thing to say. No, you don't. I have no idea why you would think that. > What are the four CRUD operations for it? [...] In which case "delete" could be ill-defined Not every method has to be valid for every resource. It's…

>>what resource is it acting on? >The distance between the two cities. Don't be cute. What server resource is it acting on? The value of the distances is (potentially) computed by some encapsulated algorithm -- you're not acting on that resource. The server resources that are touched are the two cities, and then whatever it does behind the scenes. >This is a really weird thing to say. No, you don't. I have no idea wh…

GET /cityDistance?city1=Chicago&city2=Austin

Also, while POST can mean "create", it can also mean "append" or "process some arbitrary request."

Re: When REST isn't Good Enough

#92

Post by jon_moore » Wed, Nov 28, 2012, 3:05 AM UTC

SilasX wrote: post #83

bct wrote: post #60

Earlier quoted context omitted.

No, the problem space being "scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components". This merely happens to overlap significantly with the requirements of public APIs. I have difficulty imagining your distance calculator needing any of those things, though.

>No, the problem space being "scalability of component interactions, ... >I have difficulty imagining your distance calculator needing any of those things, though. Right, because no one's stupid enough to use (or stick to the use of) REST for a distance calculator or any other algorithmically generated information. But make no mistake, scalability of component interaction is an issue, just a solved one (for those tha…

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.

Re: When REST isn't Good Enough

#93

Post by SilasX » Fri, Nov 30, 2012, 10:12 PM UTC

jon_moore wrote: post #91

SilasX wrote: post #84

Earlier quoted context omitted.

>>what resource is it acting on? >The distance between the two cities. Don't be cute. What server resource is it acting on? The value of the distances is (potentially) computed by some encapsulated algorithm -- you're not acting on that resource. The server resources that are touched are the two cities, and then whatever it does behind the scenes. >This is a really weird thing to say. No, you don't. I have no idea wh…

GET /cityDistance?city1=Chicago&city2=Austin Also, while POST can mean "create", it can also mean "append" or "process some arbitrary request."

>GET /cityDistance?city1=Chicago&city2=Austin

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".

Re: When REST isn't Good Enough

#94

Post by SilasX » Fri, Nov 30, 2012, 10:20 PM UTC

jon_moore wrote: post #92

SilasX wrote: post #83

Earlier quoted context omitted.

>No, the problem space being "scalability of component interactions, ... >I have difficulty imagining your distance calculator needing any of those things, though. Right, because no one's stupid enough to use (or stick to the use of) REST for a distance calculator or any other algorithmically generated information. But make no mistake, scalability of component interaction is an issue, just a solved one (for those tha…

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".