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

321–330 of 351 posts

Re: REST is the new SOAP

#321

Post by mathw »

So my problem is that REST stuff is usually a horrible mess with lots of special-casing, while SOAP gets ridiculously leaky and requires very tight coupling and lots of tooling to allow servers or clients to implement it cleanly, because the envelope formats etc. are really complex. If you've got something which can consume the WSDL and generate client code then you're good - provided it has a sane connection handler etc. etc. etc. because usually in my experience they then try to do too much for you and are very vague about what that actually is.

Needs something else. Preferably something already invented. My employer has a SOAP API which is very annoying, written in a framework that lets us throw any exception we like back to the clients, thus exposing internal details by accident in an interface which we then can't change because people might be processing those exception names to understand the errors they're getting when their requests aren't valid. This is where the idea of RPC needs a gatekeeper (oh for a framework-level option to say "you can only throw exceptions to the client which are in this namespace" or maybe "only ones which derive from an class in this namespace").

We also have a REST API, which is reasonably good at hitting the RESTful ideas, but not great everywhere because yup, there's that ambiguity in the conceptual framework itself.

There's also a lot of code involved in actually consuming the thing.

I need to read up on alternatives. But our customers aren't going to change any time soon!

Re: REST is the new SOAP

#322

Post by 3pt14159 »

0x445442 wrote: post #320
3pt14159 wrote: post #319

Earlier quoted context omitted.

But you can with REST. Most of this conversation is a strawman against REST. Creating or changing resources can impact other resources. It's obvious / logical. Responses can include the things that they impacted along the way. Much of this thread amounts to "I used this shitty REST API once" or similar for RPC.

Well, it depends on how you reckon REST. I can assure you the real world issues I've run into don't have anything to do with the frameworks used. The impedance mismatch between what one would consider a sane API that could just as easily be implemented as a compiled library and the mappings of that API to HTTP verbs and what is considered proper REST were where the problems were. My question would be, outside of conv…

I don’t really remember SOAP since that was over a decade ago, but what I like about REST is that it harmonizes the front end and backend structures of the application and it makes things predictable. It also puts up some guardrails against obviously dumb behaviour like deleting records via a GET and with JSON API, makes it possible for things to snap together once you’ve got the structure right. Ember Data + Rails set up to follow JSON API is just unbelievably productive. Pagination, filtering, optionally including other resources, linking (both to the related resource itself and to the relationship itself) it’s really fast, consistent, powerful, flexible, and secure. It’s not always performant, but when performance is important I make one little RCP or nonstandard REST endpoint (say return a link to a big TSV blob) and I move on with life.

Re: REST is the new SOAP

#323

Post by thehardsphere »

mistermann wrote: post #215
thinkpad20 wrote: post #167

Earlier quoted context omitted.

The article laid out a detailed explanation of shortcomings of REST. You might not agree with everything in it, but you offer no real rebuttal, instead dismissing it as a “hateful hipsteresque opinion,” without acknowledging any of the actual criticisms the author gave. This strikes me as unfair, haughty and lazy.

There's quite a "circle the wagons" mentality common in programming nowadays, following politics lead I suppose.

Nah, that was in programming well before politics.

They can have the same root cause though: someone's identity feeling threatened.

Re: REST is the new SOAP

#324

Post by thehardsphere »

rwmj wrote: post #39
bbarn wrote: post #14

Earlier quoted context omitted.

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.

Or in the case of SOAP, simply cannot work out how to consume it. In at least one case there was a SOAP service offered and I had a good quality SOAP client library in a popular language and I couldn't work out how to make a single working request.

Really? Was something wrong with the WSDL?

Re: REST is the new SOAP

#325

Post by thehardsphere »

ngrilly wrote: post #159
Yokohiii wrote: post #106

Earlier quoted context omitted.

Reading the article I wondered why we even integrate services so deeply with HTTP. The things I care about is the ability to cache at HTTP layer and the option to move endpoints. Which can be added indepentendly of the actual protocol. Moving a service to another protocol than HTTP could be an interesting option.

I think some reasons for still using HTTPS as a starting point are the ease of proxying (load balancing), the support for virtual server names, the fact it's easy to use from a web browser, the built-in encryption with TLS.

Plus, for any given large organizational customer HTTP/HTTPS are allowed through their firewall/other network security apparatus, wheras other ports require a bunch of special exceptions from the security people to use. Said people often refuse to give exceptions no matter how reasonable the request might be, so everybody ends up doing everything on port 80 or 443.

Re: REST is the new SOAP

#326

Post by thehardsphere »

quantumofmalice wrote: post #229

REST isn't appropriate as a description of JSON-based apis because JSON isn't a natural hypertext and thus makes HATEOAS difficult to implement. Most JSON APIs described as REST are really RPC APIs with a bit of URL layout taken from the REST world. Unfortunately XML-RPC was such a nightmare that calling something JSON-RPC was out of the question. Shame. There are a few blog posts up on the intercooler website that d…

There is a thing called JSON-RPC: http://www.jsonrpc.org/specification

The author explicitly mentions it as something he prefers over REST (though he spends more time on XML-RPC)

Re: REST is the new SOAP

#327

Post by ngrilly »

thehardsphere wrote: post #325
ngrilly wrote: post #159

Earlier quoted context omitted.

I think some reasons for still using HTTPS as a starting point are the ease of proxying (load balancing), the support for virtual server names, the fact it's easy to use from a web browser, the built-in encryption with TLS.

Plus, for any given large organizational customer HTTP/HTTPS are allowed through their firewall/other network security apparatus, wheras other ports require a bunch of special exceptions from the security people to use. Said people often refuse to give exceptions no matter how reasonable the request might be, so everybody ends up doing everything on port 80 or 443.

Fully agree with this (from experience)...

Re: REST is the new SOAP

#328

Post by thehardsphere »

kapad wrote: post #166

I read the article upto the point where they consider using rest to create an entry into the rest_password_email table or some such thing. That's stupid and ludicrous. That isn't even a use case for REST. I think the writer needs to consider taht http APIs cover many different use cases with subtle differences. REST exists to solve the problem for one of those use cases, i.e. data model interactions over HTTP. But HT…

>Now, onto RPC. RPC, is binary protocol over TCP.

The author specifies two different RPC protocols in their article: XML-RPC and JSON-RPC. Both often do push plain text over HTTP.

> REST, IMO, derives most of it's flexibility from being built over HTTP, and not because REST is some kind of magic sauce that it's touted by many to be

In that case, there is no difference between REST, XML-RPC, JSON-RPC, and SOAP. That could be a valid opinion to have, but I suspect it’s not one most people would agree with.

Re: REST is the new SOAP

#330

Post by IanCal »

hamilyon2 wrote: post #329
deniska wrote: post #208

Earlier quoted context omitted.

HTTP server following the spec can omit the body from a GET request.

I'd love to see a document defining this. I could not find such to the date.

I'm not too up on which documents here are current but at least:

> A payload within a GET request message has no defined semantics;

> sending a payload body on a GET request might cause some existing

> implementations to reject the request.

https://tools.ietf.org/html/rfc7231#section-4.3.1

Post reply on HN