REST is the new SOAP • Hacker News Board

Re: REST is the new SOAP

#31

Post by adrianmsmith » Sat, Dec 16, 2017, 9:12 AM UTC

I think there’s something even more fundamental.

The article talks about how to communicate between systems. But many systems don’t need to be distributed.

If you can avoid writing a distributed system, that’s easier than even a “better REST”, if such a thing were to exist.

For example, old-style non-SPA web applications, can directly use underlying logic classes directly, can throw exceptions, need not serialize data, one connection to the DB with one transaction capable of rollback, and so on.

Or monolithic servers rather than microservices.

Sometimes you need RPC, but for those situations where you don’t, avoiding RPC completely is a significant reduction in complexity.

Re: REST is the new SOAP

#32

Post by magic_quotes » Sat, Dec 16, 2017, 9:12 AM UTC

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…

The proper REST API should be specified as the set of domain-specific document formats (media-types) and have a custom browser as a client. Turns out, we already have HTML and web-browsers, so there is little point in actually building such APIs. It's always more appropriate to build a website instead. On other hand, what usually called 'REST' is nothing else but RPC where 'procedure call' = 'http method + url'. There is nothing wrong with that (with the exception of the name), but trying to satisfy any REST/HATEOAS constraints on top of RPC foundation seems difficult and pointless.

Re: REST is the new SOAP

#33

Post by speedplane » Sat, Dec 16, 2017, 9:13 AM UTC

hliyan wrote: post #16

dhoulb wrote: post #10

This article expressed a lot of what I’ve been mulling for years. I must’ve spent hours of my life poring over the Wikipedia HTTP Response Codes page, looking for the most expressive error code for my situation. It’s barmy.

You don't need to. For me, REST can be as simple as: encode the type of request into the URL, request parameters into URL parameters and/or query parameters, request data into a JSON payload. Use GET for read-only operations, and if you're really not particular about it, use POST for everything else. Return 200 for success, 400 for client error and 500 for server error. Transport a more detailed application error cod…

You don't even need that. I don't think there is anything wrong with returning a 200 response with a JSON body that has some 'error' tag built into it. It may not be purely RESTful, but if it's obvious to the developer interacting with the API, who cares.

Re: REST is the new SOAP

#34

Post by hjjiehebebe » Sat, Dec 16, 2017, 9:13 AM UTC

frik wrote: post #17

Article reads like being from a crumpy snarky old age dev who lives in his XML-land filter bubble of the 1990s. Go back to XMLRPC and SOAP please. This site is getting more of these corporate old farts lately that don't want to adjust at all. I wish the time back when this site was about startup news, VCs, and new exiting things and not about whining and boring stuff.

No need for the ad hom.

Re: REST is the new SOAP

#35

Post by drawkbox » Sat, Dec 16, 2017, 9:14 AM UTC

REST can be as simple as you want it to as verbose and rigid as you want it. Defining an API has certain public expectations such as request/response and basic HTTP status codes, but again can be easy or more detailed. There are RESTafarian and pragmatic ways to implement REST APIs.

Much of the problem of any tech becomes that engineers/developers are supposed to make complex things simple but instead sometimes make simple things more complex because it seems smarter. Complexity is needed only enough to make it simple to interface with and consume. REST is an example of web services done right and more simple compared to SOAP which was supposed to be the Simple Object Access Protocol but they forgot the simple part and just kept adding layers.

APIs should be easy to work with and as non changing as possible in the public signatures and routes/data/configs or else versioning should come in on major changes which should be handled wisely. Sometimes that is RESTafarian or pragmatic, sometimes more HTTPRPC, sometimes that means schemas for consumption, sometimes pretty urls, sometimes ids and name blurbs, sometimes responses wrapped in app messages/wrappers, sometimes directly on HTTP(s) response bodies, and it all depends on if it is public or private and if you control both endpoints, the clients and business needs.

Re: REST is the new SOAP

#36

Post by speedplane » Sat, Dec 16, 2017, 9:19 AM UTC

magic_quotes wrote: post #32

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…

The proper REST API should be specified as the set of domain-specific document formats (media-types) and have a custom browser as a client. Turns out, we already have HTML and web-browsers, so there is little point in actually building such APIs. It's always more appropriate to build a website instead. On other hand, what usually called 'REST' is nothing else but RPC where 'procedure call' = 'http method + url'. Ther…

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 explicit, the developer knows it relies on the network and accordingly that it may fail. Developers will be more inclined to plan for errors when the possibility of such errors are more obvious.

Re: REST is the new SOAP

#37

Post by adrianmsmith » Sat, Dec 16, 2017, 9:19 AM UTC

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 which makes your life more difficult, to solve problems you don’t have and cannot foresee.

So you choose something simple. But you run into all these problems anyway, because they exist, no matter if you were capable of foreseeing them or not.

But by then it’s too late. You’ve written 50 KLOC and you just have to keep going.

I believe this is why many technologies become popular which are actually too simple to handle the types of problems they try to solve.

I blogged about this concept here: https://www.databasesandlife.com/the-cycle-of-programming-la...

Re: REST is the new SOAP

#38

Post by felipelemos » Sat, Dec 16, 2017, 9:33 AM UTC

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…

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

Re: REST is the new SOAP

#39

Post by rwmj » Sat, Dec 16, 2017, 9:34 AM UTC

bbarn wrote: post #14

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…

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.

Re: REST is the new SOAP

#40

Post by kowdermeister » Sat, Dec 16, 2017, 9:38 AM UTC

We now recently had to design an internal system to manage student data. We went with REST and the first thing I did is to document all API-s in a repository using Swagger.

It's not really true that there are no standards, they defined Open API, it has a nice browser based editor to update the YAML files and it's easy to read an maintain.

All changes to the API-s are done via pull requests, so changes are reviewed.

The HTTP verb is also a non issue, there's 4... FOUR that you need to match with CRUD. Is that hard? Even if it is, read the docs.