Live data from Hacker News

REST is the new SOAP

medium.com

121–130 of 351 posts

Re: REST is the new SOAP

#121
post #7

Earlier quoted context omitted.

> Honestly, REST is a great idea. Yes, people get religious about HTTP verbs and URL structures. But you don’t need to. Prioritise clarity to humans above everything else, and you’ll be fine for the most part. I've seen this argument before (I've even made this argument before), but I'm becoming increasingly unconvinced by it. Let me explain my thinking: 1. If there's ANYTHING that sets REST apart from a generic HTTP…

> but in that case, you'd just have a /login and /logout endpoints, you'd do a POST to the former with a valid username/password to login, and a POST to the latter to log out, the end. That's super clear, and super usable, but nothing about that is RESTful. And this is the beauty, compared to SOAP: you can mix-and-match. Make your resources as RESTful as possible (but e.g. omitting passwords/cc numbers), and implemen…

Came to make this exact point. Use a framework to automatically give you a solid, dependable REST api focussed purely on crud operations on your core data model. Anything weirder than that (which I don’t believe will be ten times the volume for the vast majority of use cases), do in the cleanest way possible, even if that means you end up with a non-REST api wrapping a core RESTful one.

Re: REST is the new SOAP

#122

Earlier quoted context omitted.

Sure. Those are conveniences. However, most of the Getting Started articles that you find about any publicly published REST API usually starts you off with a bunch of curl commands. Even if the networking aspects are completely hidden from you in your application, your formative experiences with the REST API almost certainly was with the network requests.

Given the dozens of languages and libraries that interact with APIs, I don't see the issue of starting with a curl command. It's a common denominator, programmers of almost all languages understand, like international sign language. No one would seriously use curl commands in production, but load up a command window, and it's an easy way to start messing around. Agree with your second point though... network requests…

I do use curl commands in production for stuff like user data in an aws cloudformation template. Having an api I can hit with curl that returns json I can parse with jq is super convenient.

Re: REST is the new SOAP

#123

Earlier quoted context omitted.

How exactly do you think REST is easier to debug and what alternatives are you comparing it to?

Crafting REST request with JSON payload is significantly easier than doing that with SOAP (or, rest it in peace, CORBA).

The author was comparing REST to json-rpc. Nowhere in the article does he propose that people use SOA or CORBA.

Re: REST is the new SOAP

#124
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…

I happen to have worked with the system author coded/maintained. We're not in touch and I'm not here to defend him, but he's no hipster. Rather, he had to integrate a lot of heterogeneous services, as that system was acting like a hub between many departments in the company, with various tech skills and resources. If anything, I suspect he's more kind of unsatisfied by changes that he deemed unnecessary. As a note as…

Xmlrpc is incredibly underappreciated.

Re: REST is the new SOAP

#125

Earlier quoted context omitted.

I happen to have worked with the system author coded/maintained. We're not in touch and I'm not here to defend him, but he's no hipster. Rather, he had to integrate a lot of heterogeneous services, as that system was acting like a hub between many departments in the company, with various tech skills and resources. If anything, I suspect he's more kind of unsatisfied by changes that he deemed unnecessary. As a note as…

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

Re: REST is the new SOAP

#127
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…

Slight aside but I tend to use POST to create a new "search results document" and the GET that document to see the actual results.

Re: REST is the new SOAP

#128
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…

Because there is no "booo" button. Every post in medium just have Likes or none, you can like or comment just that, making a critical comment is to much for most of the users that just want to say "I disagree"

If medium has some kind of down vote, it will regulate itself a lot more, and users that disagree will not have to go to make a comment and expose themselves being critical.

Right now is full of "Content Hackers" trying to make reputation.

Re: REST is the new SOAP

#129
We 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 RPC, such a change will require a major redesign of the system. The resource-oriented world view of REST is very different from the procedure-call oriented XML-RPC. You really need to clarify what benefit you hope to achieve before attempting such a redesign.

The problem with the article is it doesn't really consider the use cases where REST is appropriate and when it is not. Rather it blames anything on the protocol itself which is considered "good or "bad" completely disconnected from use cases.

> And you’re gone for hours, reinventing the wheel.

So don't do that. The fault lies not with the technology.

Re: REST is the new SOAP

#130

Earlier quoted context omitted.

And REST is easier to debug. This make a huge difference when you have a big and complex system.

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 headache going forward.

Post reply on HN