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

191–200 of 351 posts

Re: REST is the new SOAP

#191

Post by combatentropy »

adrianmsmith wrote: post #28
gjjrfcbugxbhf wrote: post #11

The author seems confused between 401 (not logged in) and 403 (user doesn't have permission).

Agreed: 401 is for authentication and 403 for authorization. Yet the official name for 401 is 401 UNAUTHORIZED. So even the very basics of REST and HTTP are confusingly or ambiguously defined.

The old spec, https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html, seems to say that 401 can mean either unauthenticated or unauthorized. If you haven't signed in, it means unauthenticated. If you have signed in, then it means unauthorized. Were the status codes written before authenticate and authorize had the narrow meanings of today?

Meanwhile, 403 seems to be reserved for when the server just generally doesn't want to do what you're asking it to do. It may tell you, it may not, it doesn't have to tell you, so there. "Authorization will not help..."

Re: REST is the new SOAP

#192

Post by jwilk »

IanCal wrote: post #61
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.

> Can I send a large request body with a GET?

Why not?

Re: REST is the new SOAP

#193

Post by ausjke »

My understanding is that RESTful is good for public WEB APIs, however for tightly-coupled systems the best was SOAP/Xmlrpc.

Nowadays the best middle ground probably should a SOAP-like wrapper for JSONRPC(instead of XMLRPC), i.e.using JSONRPC as the payload instead of XML, does such thing exist?

https://en.wikipedia.org/wiki/SOAPjr was one effort to combine SOAP with JSONRPC, but seems not getting traction.

So, SOAP/XML too verbose, RESTful not good for tightly-coupled systems, what other options do we have, ideally have something like SOAP but using JSONRPC?

Re: REST is the new SOAP

#194

Post by cptskippy »

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…

> that SOAP pain

The pain you're referring to is relative to the language you used and when you touched it. SOAP is a comprehensive and we'll defined specification and when implemented properly you forget it's there because it just works.

After about 2003 major vendors had their implementations locked down pretty well. In Visual Studio you just implement a basic controller and the remainder is configuration. If you wanted to consume something from Biztalk, PeopleSoft, any Oracle Product, or any other Enterprise product you could just add a service reference to a WSDL URI and a tool would generate your interface classes and DTO classes for you in your language of choice.

In the Open Source world things were very different. Whenever I would provide a service to be consumed by a vendor, I would provide reference implementations in C#, JAVA, Python, and PHP. I would spend about 15mins on C# and JAVA, then the rest of the day fiddling with Python and to a lesser extent PHP.

PHP and Python have had SOAP libraries for a decade but they require considerably more effort to even consume SOAP. I have never tried to stand up a SOAP Service with them but I can't imagine it's any good.

Around 2012 I remember working with a partner company that was using RAILS for their platform. It was an absolute nightmare for them to integrate with our existing SOAP service layer. SOAP protocol libraries were the least of their issues. No client certificate authentication in their HTTP libraries. No serious XML support. They wrote their own implementation from scratch.

Re: REST is the new SOAP

#195

Post by ThrowawayR2 »

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…

> If you try to suggest something other than REST in the office you become the subject of a witch hunt.

It was the same way 15 years ago if you suggested anything other than SOAP. The more things change, the more they stay the same.

Re: REST is the new SOAP

#196

Post by bvrmn »

cptskippy wrote: post #194
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…

> that SOAP pain The pain you're referring to is relative to the language you used and when you touched it. SOAP is a comprehensive and we'll defined specification and when implemented properly you forget it's there because it just works. After about 2003 major vendors had their implementations locked down pretty well. In Visual Studio you just implement a basic controller and the remainder is configuration. If you w…

> I have never tried to stand up a SOAP Service with them but I can't imagine it's any good.

Python has decent SOAP server implementation with one-to-one request/response schema modeling https://github.com/baverman/dropthesoap

Re: REST is the new SOAP

#197

Post by dec0dedab0de »

pixie_ wrote: post #43
speedplane wrote: post #36

Earlier quoted context omitted.

Don't agree at all. There is a huge difference between calling a function "foo()" that makes an RPC call and the relatively equivalent REST call "http.GET('/foo')". The former feels like a function call, and callers will assume it operates like one. However, in reality the former is not a function, it's making a network call, and it's incredibly unreliable. In theory, the latter does the same thing, but it's far more…

What's funny is that most consumers of REST APIs do it through a wrapper that turns it back into a statically typed RPC. REST truly is a useless middleman that no one realizes they just don't need.

I doubt that most consumers of REST APIs are doing anything statically typed. I would guess that the vast majority of REST consumers are written in browser javascript. Server side, I bet at least half are written in a dynamic language.

Re: REST is the new SOAP

#198

Post by andrewflnr »

bthornbury wrote: post #52
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…

You're right of course, like the first time you hit a race condition (with a week of debugging) and build a distributed lock system. You publish it and people find it useful! Only to realize later postgres offers fine locking capabilities far beyond what you've created (now that you get it). Then you realize that all anybody is doing is creating subsets of Erlang (half serious). So why aren't we all using that? In th…

Exploration will be far more effective, and get farther, if it learns from previous expeditions, starts from established frontier outposts, etc.

Is there a superset of Common Lisp and Erlang? Such a language would be unmatched for already containing everyone's clever ideas!

Re: REST is the new SOAP

#200

Post by sidlls »

speedplane wrote: post #67
pixie_ wrote: post #49

Earlier quoted context omitted.

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

Why does that matter? Most of the time the client doesn't care about the implementation details of the data transfer.
Post reply on HN