I am working on a SOAP service and it is a nightmare.
REST is the new SOAP
151–160 of 351 posts
Re: REST is the new SOAP
#152Man, it's almost like representational state transfer and remote procedure calls are two different things, and sometime your service does fine with the simpler one of those, and other times your service needs finer-grained controls.
But if we were thinking critically about how these protocols differed then we couldn't write an entertaining polemic, right?
Re: REST is the new SOAP
#153I 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.
But like the article mentioned, clients using REST are used to dealing with wrappers written for their language anyway. They'd prefer to not bother with URLs, query strings, and MIME types, and simply consume an API in the language that feels natural for them.
You can argue that REST is easier to debug for developers, but nothing makes XML-RPC or binary protocols inherently _less_ easier to debug. It depends on the platform and library you're using.
I wholeheartedly agree with the article. Well done.
Re: REST is the new SOAP
#154Earlier quoted context omitted.
Programming Paradigm Becomes Popular B/C it gets stuff done --> left: it gets stuff done because it's smarter right: it's bad for you, it's actually getting less done middle: didn't read all that stuff, busy getting stuff done.
didn't read all that stuff, busy getting stuff done. I agree with this. When I end up on a new project and I'm not the lead, and there is a lead who is pedantic regarding how they want their URLs crafted (or wants to implement a complicated query pattern, or introduce an extra layer of objects to satisfy an abstract notion of purity), I'll just go with the flow. Accidental complexity, pattern seeking and cargo-cultin…
The problem becomes evident when you return to the results so the flow a year later to change something, and wish you were more mindful when getting things done.
Cargo cults are not good. Finding and adhering to regular patters that logically underlie what you do saves time and mental effort, while also preventing certain classes of errors. (No, these are not GoF design patterns.)
Re: REST is the new SOAP
#155Earlier 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
[deleted]
Re: REST is the new SOAP
#156Earlier quoted context omitted.
I agree. My main goal building an API is to make it easy to consume. Clients are lazy and impatient, and this is a good thing because it makes the developers work hard to make it easy to connect to their API.
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..
I think they were suggesting that it was more difficult to design/develop (as per your example), but easier to consume if designed/developed well, and that this was the proper tradeoff.
Re: REST is the new SOAP
#157Earlier quoted context omitted.
didn't read all that stuff, busy getting stuff done. I agree with this. When I end up on a new project and I'm not the lead, and there is a lead who is pedantic regarding how they want their URLs crafted (or wants to implement a complicated query pattern, or introduce an extra layer of objects to satisfy an abstract notion of purity), I'll just go with the flow. Accidental complexity, pattern seeking and cargo-cultin…
The problem becomes evident when you return to the results so the flow a year later to change something, and wish you were more mindful when getting things done. Cargo cults are not good. Finding and adhering to regular patters that logically underlie what you do saves time and mental effort, while also preventing certain classes of errors. (No, these are not GoF design patterns.)
I’m certainly not advocating spaghetti code, balls of mud, or a thoughtless lack of architecture. What I’m specifically referring to is wilful anti-pragmatism that betrays a sort of insecurity...it’s hard to define but easier to recognize.
Finding the balance between pointless over-engineering and rigidity on one hand, and good software design on the other, consistently, is what seems to distinguish great programmers I’ve worked with, from those who are “just” very good.
But, like I said, it often isn’t worth the trouble fighting about these things, even when we see them, and getting on with the job is more important than ensnaring oneself in religious debates on projects.
Re: REST is the new SOAP
#158I 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'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…
How is it any different in any way than any other async function? You just end up providing an unusually large number of parameters via headers and body, then at some point in the future the request completes with values and/or errors. What separates them?
Re: REST is the new SOAP
#159I 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…
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.
Re: REST is the new SOAP
#160I 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…
Yup. It's the mechanism behind programming as a pop culture. Kids without a lot of experience are sick of the old way because it's too hairy and complicated, they come out with a fresh new approach that isn't nearly as broadly applicable, then it gets improved until it's fit for general purpose, at which point it's hairy and complicated and the cycle starts again. I don't think that everything is standing still, thou…
The best technologies can be understood and used in a simple case by a beginner but still "unfurl" to handle the general case.
The worst force you to embrace the entire complexity before you can even hello world.
Progress is being made.