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

REST is the new SOAP

medium.com

Post reply on HN
Print view View original

61–70 of 351 posts

Re: REST is the new SOAP

#61

Post by IanCal »

uiri wrote: post #3

POST represents a non-idempotent operation. The other HTTP verbs (GET, PUT, PATCH etc) are idempotent. The awkwardness surrounding PUT/PATCH stems from the need to ensure that those requests remain idempotent. Nothing bothers me more than an idempotent request (e.g. a search query) using POST. If you design your API starting with "what should happen if the client makes this request multiple times?", then it becomes m…

Can I send a large request body with a GET? That's usually the reason I end up with POSTs.

Re: REST is the new SOAP

#62

Post by cm2187 »

lfischer wrote: post #59

Maybe REST was the best protocol for the great public API explosion of the past decade, where startups wanted to expose a public API to anyone on the internet. The most important requisite was that the most developers could access the API with a minimum of technical knowledge and tools, and the APIs were simple. I am less and less sure that REST is the best solution for communicating between internal services, which…

What do you think is a better solution?

Re: REST is the new SOAP

#63

Post by speedplane »

merb wrote: post #50
speedplane wrote: post #33

Earlier quoted context omitted.

You don't even need that. I don't think there is anything wrong with returning a 200 response with a JSON body that has some 'error' tag built into it. It may not be purely RESTful, but if it's obvious to the developer interacting with the API, who cares.

well most consumers work better with 400 errors. (i.e. angular1 or even angular2 where the 4xx error codes will be inside the error clause of the promise/observable)

There are probably hundreds of http clients, not sure if "most" handle error codes elegantly, I know that python's base urllib library does not.

Re: REST is the new SOAP

#64

Post by iovrthoughtthis »

adrianmsmith wrote: post #37

I think there’s a tendency in software for people to start out without understanding all the complexities they’re going to encounter. I think this is just human nature. When you start out doing RPC you think, I don’t want to bother with schemas, I don’t want to bother with hierarchical error codes, I don’t foresee the need to set the user’s password but not retrieve it. So you don’t want to bother with a technology w…

I think that approach of creating abstractions and concepts just in time is good tbh. It allows for thing to get incrementally complex. I wish there were a way to manage concepts through that process so that you could have all of the simple, easy to change stuff for new concepts while using the more comprehensive and often complex stuff for more "hardened" concepts.

Re: REST is the new SOAP

#65

Post by lfischer »

bbarn wrote: post #14
pixie_ wrote: post #8

I agree 100% with this article. A simple RPC API spec takes minutes to define. 'Rest'ifying takes much longer, there are a million little gotchas, no real standard. Everyone has a different opinion of how it should be done. Data is spread across verbs, urls, query params, headers, and payloads. Everyone thinks everyone else doesn't 'get' REST. If you try to suggest something other than REST in the office you become t…

Well, I'm glad you can put together an RPC api that quick, but the reason REST is so ubiquitous and why arguing against it is going to make you the subject of a witch hunt is because it's so easy to consume. Your API is useless if people don't want to use it.

Not all APIs are public though. You could picking a communication protocol among services within a single technical organization. In that case you can decide to train everybody to use Thrift, for example, if the pros are strong enough.

Re: REST is the new SOAP

#66

Post by speedplane »

IanCal wrote: post #51
speedplane wrote: post #30

Earlier quoted context omitted.

The problem is the assumption of a "simple RPC" protocol... there is no such thing. There are network issues, proxy errors, and two-sided race conditions that complicate any network related code. Network programming is distributed programming, which is not easy. RPC protocols try to mask that difficulty, but more often than not they sweep it under the rug. RPCs make it easy to get started on a dev machine. making net…

I don't see how those things are really solved with rest, particularly given that people will often be using a wrapper rather than building their URLs manually everywhere.

Definitely not "solved", just made more explicit, kind of like a warning sign in the road. A while ago I worked with an RPC system where the RPC calls looked just like normal function calls... everything worked well, until it didn't.

Anytime a computer program consumes a potentially scarce resource (e.g., network, disk, database, etc), there should be some warning-sign or flag raised to the developer. RPC hides that, whereas REST makes it more explicit. So much of programming is social, and the mechanics of REST, even though theoretically identical to RPC, raise many social flags warning of danger ahead.

Re: REST is the new SOAP

#67

Post by speedplane »

pixie_ wrote: post #49
speedplane wrote: post #29

Earlier quoted context omitted.

If you're defining an RPC protocol in just a few minutes, you're leaving a ton of stuff out. Anyone that assumes an RPC call will successfully complete or assumes the network is always there, is writing buggy code. An "RPC protocol" makes writing such buggy code easier. A REST protocol makes it slightly harder. In theory, they are almost identical. But in practice, developers equate RPC calls with function calls, whi…

Too bad the first thing people do when consuming a REST API is to put a RPC wrapper around it (or find software that with auto-gen a wrapper for them) Subconsciously no one wants to deal with your carefully constructed REST URLs. They just want a function name and some parameters.

There's nothing wrong with wrapping REST APIs, as long as you wrap them in something that makes it clear they are a rest API. There's a huge difference in call foo() and calling http.get("foo").

Re: REST is the new SOAP

#68

Post by speedplane »

IanCal wrote: post #56
speedplane wrote: post #33

Earlier quoted context omitted.

You don't even need that. I don't think there is anything wrong with returning a 200 response with a JSON body that has some 'error' tag built into it. It may not be purely RESTful, but if it's obvious to the developer interacting with the API, who cares.

That means I can't use any kind of generic retry / back off code because I've now got to start dealing with your custom errors, and if you have html versions of the info Google will start demoting you. Just add a code, it's seconds of work.

You're assuming you want your API to work with a specialized crawler, like Google-bot. If that's important, then sure, design your API so Google-bot can crawl it nicely, but then it's Google designing your API, not you.

Re: REST is the new SOAP

#69

Post by lfischer »

cm2187 wrote: post #62
lfischer wrote: post #59

Maybe REST was the best protocol for the great public API explosion of the past decade, where startups wanted to expose a public API to anyone on the internet. The most important requisite was that the most developers could access the API with a minimum of technical knowledge and tools, and the APIs were simple. I am less and less sure that REST is the best solution for communicating between internal services, which…

What do you think is a better solution?

I don’t know yet because I haven’t had as much experience with other solutions as with REST. I am curious about Thrift and Protocol Buffers. I have worked once on a project migrating from REST to Protocol Buffers for an internal API and it noticeably improved performance, but code complexity remained more or less the same.

Re: REST is the new SOAP

#70

Post by snarfy »

speedplane wrote: post #33
hliyan wrote: post #16

Earlier quoted context omitted.

You don't need to. For me, REST can be as simple as: encode the type of request into the URL, request parameters into URL parameters and/or query parameters, request data into a JSON payload. Use GET for read-only operations, and if you're really not particular about it, use POST for everything else. Return 200 for success, 400 for client error and 500 for server error. Transport a more detailed application error cod…

You don't even need that. I don't think there is anything wrong with returning a 200 response with a JSON body that has some 'error' tag built into it. It may not be purely RESTful, but if it's obvious to the developer interacting with the API, who cares.

Yep and when I have to investigate production issues, you're the guy that makes me do slow wildcard queries of the detailed error text instead of just filtering on the (indexed) response code. You push your laziness onto the rest of the world that way.
Post reply on HN