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

71–80 of 351 posts

Re: REST is the new SOAP

#71

Post by harryf »

felipelemos wrote: post #38
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.

And caching is easy to implement independently of the API using a proxy

Re: REST is the new SOAP

#72

Post by nitrogen »

adrianmsmith wrote: post #37

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 w…

Then you have phase two of engineer development, where having been burned by something surprising engineers overbuild everything. That's when you get technologies that are too complex to handle the problems they try to solve. That's when you get seven layers of dependency injection for something that could be a single-line algebraic statement with five variables.

Re: REST is the new SOAP

#73

Post by addicted »

qaq wrote: post #57
speedplane wrote: post #24

Lots of comments here arguing REST is popular because it's easy, but there's another higher level reason too: it forces you to think about the network. In far too many RPC protocols, calling functions that operate over a network are treated like normal functions. A function call, almost by definition, fails to take into account network errors, and race conditions where multiple events overlap. Network calls are not f…

And yet most popular "REST" APIs provide lang. specific clients that expose regular function calls to consume the API turning it into RPC.

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.

Re: REST is the new SOAP

#74

Post by q3k »

dasloop wrote: post #9
mehrdada wrote: post #6

Solution? https://grpc.io

For internal services communication, gRPC is a better option. For backend to web frontend, I will keep REST for a while although is tempting to have a unified system. For example this: https://improbable.io/games/blog/grpc-web-moving-past-restjs...

I'm currently developing a product using gRPC-Web as an interface between our client and server-side code. It's very pleasant to work with, especially when using TypeScript on the client side.

Oh, and for those who want to be able to query APIs from the command line without prior knowledge, the following works if you have reflection enabled on your gRPC server:

    q3k@anathema ~ $ alias grpc="docker run --rm -it --net=host returnpath/grpc_cli"
    q3k@anathema ~ $ grpc ls 127.0.0.1:50051
    helloworld.Greeter
    grpc.reflection.v1alpha.ServerReflection
    q3k@anathema ~ $ grpc ls -l 127.0.0.1:50051 helloworld.Greeter
    filename: helloworld.proto
    package: helloworld;
    service Greeter {
      rpc SayHello(helloworld.HelloRequest) returns (helloworld.HelloReply) {}
    }
    q3k@anathema ~ $ grpc type 127.0.0.1:50051 helloworld.HelloRequest
    message HelloRequest {
      optional string name = 1[json_name = "name"];
    }
    q3k@anathema ~ $ grpc call 127.0.0.1:50051 helloworld.Greeter.SayHello 'name: "gRPC World"'
    connecting to 127.0.0.1:50051
    Rpc succeeded with OK status
    Response: 
     message: "Hello gRPC World"

Re: REST is the new SOAP

#75

Post by peshooo »

DarkCrusader2 wrote: post #25
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…

I avoid medium posts as much as possible. Everyone is an expert on there with very strong opinions telling me how every technology older than 2 years and not written in javascript is obsolete/dead/not the right way/new . And what's with the UI on their publications. They take up top 25% of the screen with the branding and navbar and bottom 10% asking me to sign in and both sticks on the screen. Who approved that?

I use the stylish add-on for Firefox and remove the bars.

https://userstyles.org/styles/browse?search_terms=medium.com

Re: REST is the new SOAP

#76

Post by speedplane »

q3k wrote: post #74
dasloop wrote: post #9

Earlier quoted context omitted.

For internal services communication, gRPC is a better option. For backend to web frontend, I will keep REST for a while although is tempting to have a unified system. For example this: https://improbable.io/games/blog/grpc-web-moving-past-restjs...

I'm currently developing a product using gRPC-Web as an interface between our client and server-side code. It's very pleasant to work with, especially when using TypeScript on the client side. Oh, and for those who want to be able to query APIs from the command line without prior knowledge, the following works if you have reflection enabled on your gRPC server: q3k@anathema ~ $ alias grpc="docker run --rm -it --net=h…

gPRC is nice... my only two gripes are that it isn't quite as debuggable as JSON, it's often overkill, and because it moves so fast (right now) I've seen updates introduce real errors into the protocol (they are fixed in a few days, but when they occur it's a terror to debug).

Re: REST is the new SOAP

#77

Post by matttproud »

XMLRPC with WSDL was bad enough that I only had to use it once. We migrated WSDL stack to REST (2007-8), which was an improvement, but it was fraught with a fat clients for each language integration to uniformly handle SSO authorization and other sundries.

Has the author considered something built upon Protocol Buffers, which have can have reasonable versioning semantics and is portable and supports status code canonicalization, like gRPC?

Re: REST is the new SOAP

#78

Post by speedplane »

addicted wrote: post #73
qaq wrote: post #57

Earlier quoted context omitted.

And yet most popular "REST" APIs provide lang. specific clients that expose regular function calls to consume the API turning it into RPC.

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 are hard. They are not much different from real distributed programming. Making REST requests should be done with care.

Re: REST is the new SOAP

#79

Post by magic_quotes »

speedplane wrote: post #36
magic_quotes wrote: post #32

Earlier quoted context omitted.

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…

> There is a huge difference between calling a function "foo()" that makes an RPC call and the relatively equivalent REST call "http.GET('/foo')".

Is it really a useful distinction? Let's rename our 'foo()' to 'dangerously_unreliable_with_unpredictable_latency_foo()'. Is there still a huge difference?

> accordingly that it may fail. Developers will be more inclined to plan for errors when the possibility of such errors are more obvious.

That part of your comment looks suspiciously similar to the usual argument against exception handling to me.

Re: REST is the new SOAP

#80

Post by garganzol »

CORBA is the best protocol I ever dealt with. Strong contractual semantics, exceptions, interface definitions. Spiced with transparent compression, encryption and bi-directional communication. All those goodies were already available 12 years ago.

The only downside - it required a reliable and precise implementation that took a lot of efforts. I always used IIOP.NET for most of my gigs and it was excellent. I also ended up as an active IIOP.NET contributor.

CORBA ORB implementation was a fine art a few could grasp. And this was the biggest drawback - the standard was (and is) excellent, but most implementations tend to be complex and shaky.

I still actively use CORBA. The server usually offers two kind of endpoints: REST for third-party integrations (which are usually naive and simplistic), and CORBA for the system itself. I've built nice things with such architecture that involved worldwide deployments including embedded hardware. I am very proud of my involvement and the fact that I could help to improve the everyday routine for many people worldwide.

Post reply on HN