REST is the new SOAP • Hacker News Board

Re: REST is the new SOAP

#241

Post by raquo » Sat, Dec 16, 2017, 8:54 PM UTC

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…

Sounds trivially avoidable.

Access the RPC call as httpSerbice.getFoo() and make it return a Future/Promise, or even a special subtype of those. 100% obvious what it does.

You're going to be calling REST methods the same exact way anyway - you have to pass around the result of that restful http.get call somehow.

Re: REST is the new SOAP

#242

Post by einrealist » Sat, Dec 16, 2017, 9:28 PM UTC

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 have another opinion about that. Read as much medium posts aspossible, but keep a critical mind. Medium is nothing but a blog platform, not a science platform, not a news paper. Medium is important, because it makes it easy for everyone to post her/his mindset or agenda. No one has to agree with anyones opinion. But its important to know about those opinions, because it makes it easier to have a dialog.

Re: REST is the new SOAP

#243

Post by einrealist » Sat, Dec 16, 2017, 9:44 PM UTC

criddell wrote: post #211

niftich wrote: post #201

I author REST APIs and try to do them properly, with mediatypes, link relations, and all the good hypermedia stuff most people avoid. Nonetheless, the author's post reflects the sort of rant I've had to coworkers at the watercooler, or anyone who'd listen. The author nicely preempts the debate about HATEOAS and "most RESTful APIs aren't REST" and shows that the debate is part of the problem. It is. It's not a spec bu…

> The author nicely preempts the debate about HATEOAS What is the debate about HATEOAS? What's the difference between an API with and without that quality?

The difference is that a real HATEOAS API provides clients with context through the payload for all service interactions. HTTP becomes just the transport layer. Roy Fielding never wanted to point to anything else. He was inspired by how HTML enabled human-to-service interaction through a Browser (the client) and formulated an architectural style for human/machine-to-service interaction. The emphasis must be on how we design formats. Communicating the state is just freestyle, HTTP being the prominent one.

Re: REST is the new SOAP

#244

Post by e12e » Sat, Dec 16, 2017, 10:13 PM 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…

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 amenable to multilevel caching, smart client;movable data: json api js app, or smart client;movable code: js/Ajax - executing js delivered by server on client (subtly different from a "pure" js/json app (which is similar to an XML/xslt App).

I don't know why the hype of rest lead people to insist on conflating their architectures.

[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Re: REST is the new SOAP

#245

Post by Cyphase » Sat, Dec 16, 2017, 10:15 PM UTC

bvrmn wrote: post #148

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…

> Why is REST so popular? REST is not popular, there are only a few RESTful public API in the wild. The rest (unavoidable pun, sorry) are simple HTTP APIs with JSON serialization which maps with various degree of coupling to internal data layer. The main cause you don't need REST limitations to achieve same goals. OP has strong opinion about why we need to reimplement rpc over http every time for every application an…

> The rest (unavoidable pun, sorry) ...

The remainder.

Re: REST is the new SOAP

#246

Post by moca » Sat, Dec 16, 2017, 10:22 PM UTC

Both Google and Microsoft have published their API design guidelines, which are very much RESTful. Both companies have applied their guidelines to broader set of products at very large scale. At least, we have not seen alternatives that would be applicable or scalable to companies at Google or Microsoft scale.

API design is like UI design or car design or clothes design. It is a form of craft, which does take time and skills. API design is for customers to have best experience, it was never meant to save time or work for the designers.

Disclosure: contributor of Google API Design Guide.

Re: REST is the new SOAP

#247

Post by matt_kantor » Sat, Dec 16, 2017, 10:25 PM UTC

speedplane wrote: post #78

addicted wrote: post #73

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 don't think the parent commenter sees curl-centric getting started guides as an issue either. Actually from this thread's context I assumed they thought it was a good thing.

Re: REST is the new SOAP

#248

Post by pixie_ » Sat, Dec 16, 2017, 10:36 PM UTC

CydeWeys wrote: post #178

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…

I agree with a lot of the things in your post, but this one in particular has produced the most grief for me: > Don't get me started with conflating http server errors with applications errors. I've wasted so much time dealing with 404 errors that were returned by the webserver itself (not the app) because the endpoint I was hitting was wrong or had moved, and vice-versa when I was correctly hitting the app but got a…

Agreed I'm very much in favor of JSON body in, JSON response. The URL is just a way to hierarchically organize the endpoints. Just like in binary APIs where public methods are organized in classes and namespaces.

Re: REST is the new SOAP

#249

Post by pixie_ » Sat, Dec 16, 2017, 10:39 PM UTC

e12e wrote: post #244

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…

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.

Re: REST is the new SOAP

#250

Post by pixie_ » Sat, Dec 16, 2017, 10:43 PM UTC

eadmund wrote: post #236

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…

> A simple RPC API spec takes minutes to define. 'Rest'ifying takes much longer, there are a million little gotchas, no real standard. The thing is, RPC is fundamentally broken due to the nature of distributed computing, and REST is not. All the time you have to spend doing things right is … the time necessary to do things right. And REST really is very simple. The problem is the cargo-cult nature of folks who don't…

If I had a nickel for every time someone said "don't really understand REST".. often people who both think they understand it say it to each other. It's pretty funny. Guess what, we understand it fine, and we don't like it.