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

81–90 of 106 posts

Re: Who Cares about GET vs. POST? NoREST

#81

Post by jawb »

lmm wrote: post #42
jawb wrote: post #15

REST is good, better than RPC, SOAP... finally people can understand and use APIs easily and happily. The URL /customer/33245/order/8769 is perfect, looks like a directory path and reflect the relationship between the entities. Arguing about the best url, status code and best verb is the irrelevant part in REST. Why can't people just do whatever it works for the users while respecting the standards when they can ?!

I think you've inadvertently put your figure on the part that really matters. REST is worse than SOAP or something like Thrift for discoverability, worse for ease of use, worse for practically every criterion you could think about. The one thing it does right is being easy to explore with a web browser. So optimize for that. Make it easy for a developer to look at your API with a web browser. This means simple URLs.…

For discoverability , it's a feature not a bug, when i want to use a REST API I can read the docs written for humans not try to find my way in a WSDL. Also a will built REST API is straightforward once you know the entities that you will be manipulating. IMHO the only bad thing about REST is; it's natural for CRUD, but not as easy for non-CRUD apps.

Re: Who Cares about GET vs. POST? NoREST

#83

Post by LoSboccacc »

dragonwriter wrote: post #57
lmm wrote: post #54

Earlier quoted context omitted.

There's no WSDL or .thrift -equivalent for discovery, and no autogenerated client code which makes use harder. Getting up and running is slower because you have no way to validate that your messages are well-formed short of throwing them at the server and seeing what it sends back. What criteria are you seeing REST as better on?

HATEOAS provides both discovery and, when well-known content types are used, potentially much richer ready-to-use client code than the autogenerated host-language interfaces provided by SOAP and similar protocols.

It's not 'discovery' in the sense that you can't discover an url, change an id here and there and build an url for another product. You don't get endpoints for operations, you get operations that are valid only for that particular product and only for that particular state.

Re: Who Cares about GET vs. POST? NoREST

#84

Post by lmm »

dragonwriter wrote: post #80
lmm wrote: post #77

Earlier quoted context omitted.

Googlebot is not an automated HATEOAS client, it's solely an automated web client. Even if the web conformed to all the specifications it would still be an exceedingly atypical example of a HATEOAS API. And googlebot is nowhere near the reliability level that we would require for most use cases.

> Even if the web conformed to all the specifications it would still be an exceedingly atypical example of a HATEOAS API. The HTTP-powered Web is the prototypical REST (including the HATEOAS constraint that is part of the definintion of REST) API.

Then REST is a wrong word, one that doesn't point to a natural empirical cluster. The web is very different from all the other things that are called "REST API"s.

Re: Who Cares about GET vs. POST? NoREST

#85

Post by namdnay »

lmm wrote: post #56
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 :)

Other than XML Schema, and XML namespaces, what was wrong with SOAP? Serious question. I genuinely think it had big advantages over REST.

I would say the main PITA with SOAP is the fact that all the methods exposed by a service are on the same http endpoint. So without capturing headers you don't even know what operations are being called. Take Apache logs for example - all you'll see is a load of POST calls to /MySOAPServiceEndpoint. Whereas with a nicely designed REST service, you can at least see the gist of what is happening without additional logging.

And take testing - you need to pull out the heavy artillery (SOAP UI is very good) to test a SOAP service. Whereas REST can be done quite easily (even more so if it's GET), from a browser or a simple python script.

Not huge issues, and if you're working on a big project it won't make a big difference. But still a PITA, in my opinion

Re: Who Cares about GET vs. POST? NoREST

#86

Post by [deleted] »

lmm wrote: post #56
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 :)

Other than XML Schema, and XML namespaces, what was wrong with SOAP? Serious question. I genuinely think it had big advantages over REST.

[deleted]

Re: Who Cares about GET vs. POST? NoREST

#87

Post by lmm »

namdnay wrote: post #85
lmm wrote: post #56

Earlier quoted context omitted.

Other than XML Schema, and XML namespaces, what was wrong with SOAP? Serious question. I genuinely think it had big advantages over REST.

I would say the main PITA with SOAP is the fact that all the methods exposed by a service are on the same http endpoint. So without capturing headers you don't even know what operations are being called. Take Apache logs for example - all you'll see is a load of POST calls to /MySOAPServiceEndpoint. Whereas with a nicely designed REST service, you can at least see the gist of what is happening without additional logg…

> Take Apache logs for example - all you'll see is a load of POST calls to /MySOAPServiceEndpoint. Whereas with a nicely designed REST service, you can at least see the gist of what is happening without additional logging.

Fair enough. I always preferred to log at the "middleware" level but I guess that's a use case.

> Whereas REST can be done quite easily (even more so if it's GET), from a browser or a simple python script.

GET for everything is a large part of what the article is advocating. Once you get into "true REST" (using PATCH/DELETE/etc., maybe content negotiation) then you quickly move out of what you can test with the browser.

As for Python that was one of the things I loved about SOAP - plug the .wsdl into suds and you can test it from your Python script and you don't even need a separate doc, you can just use Python's built-in dir() and help().

Re: Who Cares about GET vs. POST? NoREST

#88

Post by namdnay »

lmm wrote: post #87
namdnay wrote: post #85

Earlier quoted context omitted.

I would say the main PITA with SOAP is the fact that all the methods exposed by a service are on the same http endpoint. So without capturing headers you don't even know what operations are being called. Take Apache logs for example - all you'll see is a load of POST calls to /MySOAPServiceEndpoint. Whereas with a nicely designed REST service, you can at least see the gist of what is happening without additional logg…

> Take Apache logs for example - all you'll see is a load of POST calls to /MySOAPServiceEndpoint. Whereas with a nicely designed REST service, you can at least see the gist of what is happening without additional logging. Fair enough. I always preferred to log at the "middleware" level but I guess that's a use case. > Whereas REST can be done quite easily (even more so if it's GET), from a browser or a simple python…

Yes I definitely agree with your last point - one of the nice things with SOAP is the autogeneration side. Same thing with Java CXF - import your wsdl and boom you have an interface with all the right methods etc, whether on client or server side.
Post reply on HN