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

171–180 of 351 posts

Re: REST is the new SOAP

#171

Post by sergiotapia »

bbarn wrote: post #13

Why is REST so popular? Because it's easy to implement and works for lots of use cases. I'm sorry that you found places it doesn't, but in the real world, having been through that SOAP pain it's being compared to, I'd say there's not even a comparison. Everyone seems to want to find a reason to dislike product/technology/feature X but in this case, X is just better than anything we've had for a 90% adoption case. Wha…

It's full of click-bait because of the opportunity for articles to go viral. Spread is built into the platform, so you have people writing the most click-bait articles possible.

Re: REST is the new SOAP

#172

Post by jeswin »

I tried some experiments earlier this year with radically simpler RPC calling conventions. It's called NSOAP, and is available for express, koa and React. It gets rid of HTTP verbs and treats the url like code. https://github.com/nsoap-official/nsoap-express

Some examples.

  //Adds two numbers
  http://www.example.com/addTwoNumbers(10,20)

  //String arguments
  http://www.example.com/search(thomas)

  //Parameters
  http://www.example.com/math.square(x)?x=20

  //Chaining
  http://www.example.com/getCustomer(100).getAccounts(2017)

Re: REST is the new SOAP

#173

Post by mgkimsal »

assafmo wrote: post #119
pixie_ wrote: post #41

Earlier quoted context omitted.

Are you assuming REST is easier than RPC to develop and/or consume? After moving to a REST based API there were endless meetings between co-workers of what is and isn't a good REST url. Our clients often come to us with dumb mistakes. Unlike RPC where the parameters go in a single place. With REST the parameters are spread across the verb, url, header, query param, etc..

Yes, I'm assuming REST is easier because of tools like curl, postman and even the major browsers with HTTP GET and great dev tools. With RPC your consumers probably need to know some coding and even maybe a specific language, a framework or a library. So yes, for me REST is easier, and I always love to see landing pages like this one - https://freegeoip.net - where the client can test the API in a few seconds by copy…

It's precisely the 'simple' examples which don't address any of the complexities in the original article. read-only properties in a resource being PUT back, for example. You're not having to deal with that with simple read-only services like freegeoip.

Re: REST is the new SOAP

#174

Post by osrec »

I find REST APIs a bit annoying, primarily because of caching behaviour. For example, if I have a GET on a list of resources and then PATCH a particular resource from the list, the browser will still keep the old list in cache and not update (with the newly patched resource) till the cache expires. For this reason, I just use my own json APIs using POST requests (to bypass the cache) with some application specific caching in the browser via indexedDB - it's not that much more work, but the experience is significantly better for the user.

Re: REST is the new SOAP

#176

Post by paulddraper »

osrec wrote: post #174

I find REST APIs a bit annoying, primarily because of caching behaviour. For example, if I have a GET on a list of resources and then PATCH a particular resource from the list, the browser will still keep the old list in cache and not update (with the newly patched resource) till the cache expires. For this reason, I just use my own json APIs using POST requests (to bypass the cache) with some application specific ca…

HTTP caching behavior is extremely flexible. You could use must-revalidate with ETag or If-Modified-Since caching.

Re: REST is the new SOAP

#177

Post by ams6110 »

mseebach wrote: post #130
barrkel wrote: post #107

Earlier quoted context omitted.

GET / POST RPC is just as easy to debug, IMO, and with less righteous orthodoxy.

The orthodoxy (aka "standard") is there for a reason. It's very easy to shoot yourself in the foot. If you're only doing small-scale internal interop, especially where you control both ends of all connections, you don't need standards, just do whatever works, but if you have scale dreams, thinking about the rules (What is 'state'? How is it represented? Where?) and why they are there will save you from a lot of heada…

Some http clients can only do GET and POST. If your API demands PUT, PATCH, or DELETE it may be less useful.

Re: REST is the new SOAP

#178

Post by CydeWeys »

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…

I agree with a lot of the things in your post, but this one in particular has produced the most grief for me:

> Don't get me started with conflating http server errors with applications errors.

I've wasted so much time dealing with 404 errors that were returned by the webserver itself (not the app) because the endpoint I was hitting was wrong or had moved, and vice-versa when I was correctly hitting the app but got a 404 error back from the API and I thought that the endpoint was wrong. And, of course, similar issues for 500 errors and the app itself dying versus the app processing normally and indicating an expected failure response via a 500 error code.

To add to all that badness, a lot of JS libraries in their async API method calls have different error handlers for success and for failure response codes, so you end up having to lump together business logic (for resources not found) and retry/error-handling logic (for the server the not working correctly) into the same failure response callback handler. It'd be much cleaner if all the business logic could be handled in a single callback and all of the failure logic could be handled in another. And, of course, you only even get to this level of badness once you figure that out; you can still waste quite a bit of time before you even realize that your callback is not being called because the JS framework is interpreting the expected 404 your API endpoint is returning for non-existent things in business logic differently than you are.

I still wouldn't go back to SOAP, but I do tend to prefer HTTPS/JSON-based APIs that don't abuse verbs, HTTP error codes, and mixes of URLs/params/headers/payloads. Better to put all of that stuff inside the JSON payload where it will only be handled by the application business logic, rather than mixing it in with all of the HTTP constructs that are used for other things as well.

Re: REST is the new SOAP

#179

Post by mgkimsal »

jchw wrote: post #142
pagutierrezn wrote: post #133

Earlier quoted context omitted.

You should read it. The title is misleading. I think the author proposes that REST is the new (failed) SOAP.

I'm remaining firmly unconvinced. REST is an anti-standard. It doesn't tell you what to do, it just gives you some guidelines of sorts. And honestly, you don't even have to follow them - the spirit of REST is in simple JSON + HTTP-based operations. As an example, this? createAccount(username, contact_email, password) -> account_id addSubscription(account_id, subscription_type) -> subscription_id sendActivationReminde…

> Or an unending number of other interpretations

and when someone joins the team and raises endless arguments with you about how what is already working isn't REST, because their interpretation is different, you have problems.

and when you have a client that insists that you're not following REST conventions because your endpoints take POST for everything and don't take actual PUT commands, and they are not going to retool their interpretation of REST to match yours, you have problems.

These problems would exist anyway - interacting with other people usually brings some problems with it - but putting things under this banner of REST implies that there is some 'right' way of doing things which contributes to the interaction problems.

Just acknowledging "hey, this could have been done 4 ways, this is the way that was chosen, deal with it" - regardless of whether the REST acronym is involved or not - should be the way to go, but an implied 'standard' creates more hurdles.

Re: REST is the new SOAP

#180

Post by 0x445442 »

Marazan wrote: post #125
regularfry wrote: post #124

Earlier quoted context omitted.

Xmlrpc is incredibly underappreciated.

Xmlrpc is simple and it works. Xmlrpc is soap without the bullshit. I built lots of personal apps that were flash/flex front ends that talked to python backends over xmlrpc to quickly whip up his for my python aps

Having implemented many web service APIs in both SOAP and REST I have the same opinion.

XMLRPC or JSONRPC seem to be the happy middle ground.

The posted article hit home with me as I had to re-implement working SOAP services in REST because you know, management buzzwords and new shiny.

I quickly found, as the article articulates, as soon as you enter the land of verbs and workflows REST starts to stumble and becomes very network chatty. And when that network chattiness is backed by other network chattiness the grumblings of why the hell you can't just return a deep object graph of data from an endpoint ensue.

Post reply on HN