[deleted]
REST is the new SOAP
261–270 of 351 posts
Re: REST is the new SOAP
#262[deleted]
Re: REST is the new SOAP
#263Why 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…
Well, that's actually where the SOAP pain is: it used to be that you couldn't make any good use of it unless you were using walled-garden vendor software. A lot of people dislike Windows, Visual Studio and anything else made by Microsoft. Same goes for Oracle. So then you are left with everything else, which basically means: everything without SOAP, Enterprise editions of runtimes, service buses and the likes.
There are a lot more developers out there not working for an enterprise and not using those tools. Especially the developers doing open source work or doing small scale work.
While nowadays it's fairly easy to make a Java Spring Boot application consume and serve SOAP, with automated WSDL imports and all the WS-* specifics, this wasn't pretty much never the case with anything new and free (as in speech).
Re: REST is the new SOAP
#264We developers need to understand there are no one-size fits all solutions. No protocol is optimal for all use-cases. Design is always a question of trade offs. Architectures are means to an end . The OP's story is a bit weird, because it seems they had a system which worked very well with XML-RPC, but they changed it to REST for no apparent reason except that "REST is the future". Regardless of the merits of REST vs…
Sorry, but these kinds of excuses always remind me of homeopathy zealots explaining why there technology didn't work in this case.
REST, just like OOP, is not a means to an end. It's fundamentally wrong. It's trying to shoehorn strange philosophical viewpoints into what's a technical problem. It's trying to decompose problems that can't be decomposed. It's... never the right solution. I've never seen it succeed. Like, ever.
Re: REST is the new SOAP
#265Those who refuse to learn history are doomed to repeat it. REST is not the end of history, there can and should be successor architectures, but RPC is not that successor. It’s been around a very long time and fell out of fashion for good reason. It is a convenient approach that can be used if you have major control over all the interfaces, endpoint implementations and underlying infrastructure, as Google does for its…
> It really falls over if you want independent implementations and variable infrastructures over a large scale, as is the case for most Internet / Web interactions.
But what exactly? I can't really think of anything that would work without an interface description (like a HTML form).
Let's have a few informal RPC signature conventions for example for retrieving a Web page (the equivalent to HTTP GET). It would make developers lives easier. But essentially there is no problem with replacing links with remote procedure calls.
Re: REST is the new SOAP
#266Yet another discussion where people talk past each other because everybody means different things by "REST". It certainly is not the "REpresentational State Transfer" as invented originally.
Now why does everybody mean different things by "REST"? Maybe because the idea "REpresentational State Transfer" was never that clear from the start.
So that's some common ground. It's a bad idea.
Re: REST is the new SOAP
#267Surprised to have scrolled this far and not see one mention of GraphQL. It has a discoverable, schema based design, strongly typed. It segments requests into three types, queries, mutations, and subscriptions. Queries are simple data fetching. Mutations can be treated like RPC calls. Subscriptions are for long lived connections to receive live updates for data queries. I think it fixes a lot of problems with REST. I…
I thought this was a snarky title for a GraphQL article. Since implementing a server in GraphQL, I much prefer it to REST
Where I'm at we have an entity component system in postgres for DB (Entity table with just an id as primary key, then all other tables only have foreign keys to the Entity table). We were implementing random REST routes which tried to line up with typeful ideas which don't exist in the DB but which the page structure of the site exposes. Switched to GraphQL, bunch of methods on a ReadEntity, an UpdateEntity, & a CreateEntity; currently implementing a clientside ECS to mirror this so that the clientside can work on intermediate entities & then submit them together. GraphQL server's real simple, just focuses on access control. Frontend gets to grab whatever components it needs for a given React component. Have ideas on how optimization can be added by adding in prefetch hints to avoid staggered loading
Sorry if this feels like a tangent hijack rant, but figured I'd drop a line on trying to explain what makes GraphQL so good
Re: REST is the new SOAP
#268Why 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…
> ...having been through that SOAP pain it's being compared to, I'd say there's not even a comparison OK, that is indeed the most usual response to "Why REST?". The main reason why people like REST is "because SOAP". It's a false dichotomy that the industry has fallen for. Oh, yeah, and you can run the GETs directly in your browser/cURL. I like that part too, but it only gives you so much. REST is more of a philosoph…
[deleted]
Re: REST is the new SOAP
#269Earlier quoted context omitted.
btw SOAP was supposed to be "xmprpc standardized" I remember well the meeting when things started to go off track...
Im actually curious now that you mention it but don’t expand on it. Was the road to hell really paved with good intentions?
I don't remember the history prior to the meeting well enough today to give an authoritative version. So for fear of getting some of it wrong I will say nothing. However, I'll say that the answer to your question is "no".
Re: REST is the new SOAP
#270Earlier quoted context omitted.
This. REpresentional State Transfer stands in opposition to Remote Procedure Calls - except for a very narrow subset of hypertext/hypermedia applications. The part I find most interesting about Fielding's thesis[1] is the introduction with architectural overview. He managed to map out modern Web apps perfectly - they can be REST (Web app with db/storage backend, perhaps extended with something like webdav) which is a…
People treat the dissertation like it is a standard. It is nothing close to a standard. It is the source of a decade of time wasted bickering over it.
Kind of my point. It's a great dissertation, with some great ideas in it. One of them is REST (Web pages). But the other architectures are well documented in there too - with trade-offs.
Ed: not sure about "time wasted bickering over it". Bickering is always time wasted. Careful analysis of software architecture, patterns, and figuring out what you're actually trying to achieve - is time well spent.
There are fundamental trade-offs between REST and different patterns - depending on where the truth of your data recides, if you need acid or not, and where (what part of) your code executes.