Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Who Cares about GET vs. POST? NoREST

swaxblog.tumblr.com

Post reply on HN
Print view View original

21–30 of 106 posts

Re: Who Cares about GET vs. POST? NoREST

#21

Post by dragonwriter »

creeble wrote: post #6
rcari wrote: post #5

Well REST allows for resources to be accessed as they are: resources. Using POST/GET query parameters implies that the server should do some actual processing on these to deliver the requested resource. With REST, you can have the resource be a static file on the server, no processing required.

I don't think you need REST to access a static file.

> I don't think you need REST to access a static file.

HTTP is a -- the prototypical -- RESTful system, and its not exactly uncommon for accessing static files on the web.

REST isn't just special-purpose APIs built on top of HTTP (nor, for that matter, does it require that an API be built on top of HTTP at all.)

Re: Who Cares about GET vs. POST? NoREST

#22

Post by dragonwriter »

Udik wrote: post #18
mbleigh wrote: post #12

Except that RPC-structured APIs are complete garbage to consume for external developers because, surprise, they don't know or care what your internal function names are. And if you aren't thinking about the experience of real or theoretical third-party developers when building your API, why even have one at all? If you ignore HTTP verbs and status codes you're just making it harder for other developers to grok your s…

Why, are external developers able to consume restful APIs without the need for any documentation on the system they're talking to? Aren't the various REST entities (and all the possible links between them, if you're doing HATEOAS) already part of a protocol the developers of external consumers need to know beforehand?

> Why, are external developers able to consume restful APIs without the need for any documentation on the system they're talking to?

In a fully RESTful, an external developer would be able to consume it with only documentation of the resource types used, and identification of a single base URI for a known resource from which the rest of the API's locations were discoverable. (That doesn't mean that an API owner wouldn't still want to document more, but it wouldn't be strictly necessary.)

Re: Who Cares about GET vs. POST? NoREST

#23

Post by mbleigh »

Udik wrote: post #18
mbleigh wrote: post #12

Except that RPC-structured APIs are complete garbage to consume for external developers because, surprise, they don't know or care what your internal function names are. And if you aren't thinking about the experience of real or theoretical third-party developers when building your API, why even have one at all? If you ignore HTTP verbs and status codes you're just making it harder for other developers to grok your s…

Why, are external developers able to consume restful APIs without the need for any documentation on the system they're talking to? Aren't the various REST entities (and all the possible links between them, if you're doing HATEOAS) already part of a protocol the developers of external consumers need to know beforehand?

I'm speaking from the experience of a developer who has built numerous public APIs and client libraries over the years. Yes, you still need documentation for a REST API (I'm not a HATEOAS utopian), but you can easily attach your documentation to concepts with which many (probably most) developers are already familiar.

The article is basically saying "You know how lots of cars have steering wheels and pedals? Well, I think it's annoying to build cars that way, so I'm going to use a system of levers and buttons." There's a ton of utility in anchoring new systems to familiar concepts, and unless you have a good reason not to you should strive to do so.

Re: Who Cares about GET vs. POST? NoREST

#24

Post by jalfresi »

tyrion wrote: post #11
treve wrote: post #4

How the url is formatted is irrelevant for REST.

Exactly, I don't understand why but it seems to me that a lot of people like to use the word REST as much as possible without knowing what it actually means, or without even having read the damn paper :(

The author CLEARLY has no idea what REST is or even why REST is used. How the hell did this garbage make it to the front page again?

Re: Who Cares about GET vs. POST? NoREST

#25

Post by dragonwriter »

ForHackernews wrote: post #16
stcredzero wrote: post #9

Earlier quoted context omitted.

OTOH, "removing information from the URL for aesthetic reasons" may not be the best reason to move a safe operation from GET, which is defined as safe, to POST, which is neither safe nor idempotent, particularly if you are using middleware that is aware of HTTP semantics -- you've just thrown away valuable information. So a part of the point of and value of GET is to communicate idempotency? We can know certain parts…

> So a part of the point of and value of GET is to communicate idempotency? We can know certain parts of the API are idempotent because they are GET? Yes: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Pedantically, RFC 2616 is obsolete, and you should point to http://tools.ietf.org/html/rfc7231#section-4.1

Re: Who Cares about GET vs. POST? NoREST

#26

Post by xienze »

dragonwriter wrote: post #10
namdnay wrote: post #7

Earlier quoted context omitted.

> advocating abandoning it completely in favor of RPC-over-HTTP It surprises me that the author didn't go one step further and ask us to return to SOAP :)

I think that we're only a few years away from someone reinventing SOAP but with JSON playing the role of XML.

And a hip name, like Dove or Ivry.

Re: Who Cares about GET vs. POST? NoREST

#27

Post by rcari »

creeble wrote: post #6
rcari wrote: post #5

Well REST allows for resources to be accessed as they are: resources. Using POST/GET query parameters implies that the server should do some actual processing on these to deliver the requested resource. With REST, you can have the resource be a static file on the server, no processing required.

I don't think you need REST to access a static file.

Sure, but how convenient it is to just generate the resource once and for all and dump it in the file system following REST semantics, thus making it useless to waste CPU cycles computing the resource contents when it's just there.

Re: Who Cares about GET vs. POST? NoREST

#30

Post by a_c_s »

Udik wrote: post #18
mbleigh wrote: post #12

Except that RPC-structured APIs are complete garbage to consume for external developers because, surprise, they don't know or care what your internal function names are. And if you aren't thinking about the experience of real or theoretical third-party developers when building your API, why even have one at all? If you ignore HTTP verbs and status codes you're just making it harder for other developers to grok your s…

Why, are external developers able to consume restful APIs without the need for any documentation on the system they're talking to? Aren't the various REST entities (and all the possible links between them, if you're doing HATEOAS) already part of a protocol the developers of external consumers need to know beforehand?

Sure, that sounds nice in theory. In the wild, how many developers (especially those working on internal APIs) have the time & inclination to thoroughly document their entire APIs? And if it exists, many developers read the entire spec of an API before beginning development? In my experience both are rare.

Given the constraints developers often find themselves under, having an API that uses common patterns most developers already understand has great value. (Ex. 'GET /customer/123' performs a safe retrieval of a representation of the customer with ID 123, no documentation required)

This leaves both developers (API creator & API consumer) free to focus on documenting/understanding the non-trivial parts of the API rather than reinventing the wheel.

Post reply on HN