Should we rebrand REST? • Hacker News Board

Re: Should we rebrand REST?

#151

Post by Communitivity » Fri, May 28, 2021, 2:12 PM UTC

tomnipotent wrote: post #137

Communitivity wrote: post #83

Earlier quoted context omitted.

You're probably right. The Thomas Erl book came out in 2004, so it was popular at least a year before that. Btw, I am a consultant. As for implementing things - there are consultants that track toward the marketing/image side of the spectrum and there are those that track toward the shipping/substance side of the spectrum, as in all things. On naming you are spot on. Being good at naming things is almost a job requir…

I only remember the timing because I was at the MySpace parent company before/during its hypergrowth, so all sorts of architectural patterns were being discussed/evaluated/used. This was during a time when complaining about SOAP/XML was the trend, greybeards liked to remind the young'uns about the nightmares of COM/CORBA, and Domain-Driven Design and Patterns of Enterprise Application Architecture were the new shiny…

> greybeards liked to remind the young'uns about the nightmares of COM/CORBA

Yeah, I dealt with COM/CORBA at its tail end too. It was horrible, but could be made to work. Was forced to use it as a key piece in a collaborative testbed and simulation framework running and communicating at 4 research centers (UK, US east, US west, AUS).

> a cheap jab at consultants

Understandable, I'm among the first to admit many consultants deserve it. One time a co-worker and I travelled from NY to our corporate mothership in VA for meetings. We got there and our first meeting was delayed. I took out my laptop and started working, trying to get some code in while we waited. My coworker took out his newspaper and read that. Same coworker told me 'He always makes sure he comes out ahead on expenses.'

> moving up the seniority ladder also meant more PowerPoints, presentations, and buzzwords.

I hear that. I get to code maybe 20% of my time now as a tech lead on a bigger project. Previous tech lead positions were on small projects where everyone needed to code as well as wear their other hats. It's a step up in pay and, in a way, impact, but I question whether I like it. I may stay pure technical. I am at least getting to code Rust in my personal time.

> get people to love my ideas, just not speak out against them

I wish more people knew that. We tried to convert people to the OASIS XDI specification, but I think W3C and others saw it as a rejection of their approach. Arguing with them to convert them just made them more vocal in their objections and eventually the standard's ratification failed. Was a decent spec, though it did need a fair bit of supporting specs still.

Re: Should we rebrand REST?

#152

Post by electroly » Fri, May 28, 2021, 2:55 PM UTC

quantified wrote: post #8

I wholeheartedly agree with the majority of this. In my experience “REST” has been like a religion in which hardly anyone either read the founding text or bothered to interpret very much of it. Fielding’s thesis does not require all of what adherents have claimed it does. An API does not a priori need to adhere to any sect of “REST”, though for many use cases it will benefit. For example, a machine-to-machine API mig…

> This API is not intended for UI usage, so why not do this?

There are HTTP clients that are incapable of sending a request body with a GET request, because the original HTTP/1.1 RFC [1] says that a client must not send a request body in a GET request. This has changed with newer RFCs, but 2616-compliant clients still exist.

If you're going to do this, you need to support POST as well, to accommodate those clients. Indeed, ElasticSearch accepts both methods. At that point perhaps you might consider whether it's worth doing just to have a conceptually clearer HTTP method. My take on TFA as it pertains to this issue would be: why bother with the strict adherence to perceived REST principles here? The search API endpoint is not a resource that you're requesting that is identified by that URL; it's an operation you're performing, so why not just treat it like the RPC that it really is?

[1] https://datatracker.ietf.org/doc/html/rfc2616

[2] "A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests"

Re: Should we rebrand REST?

#153

Post by quantified » Fri, May 28, 2021, 10:51 PM UTC

electroly wrote: post #152

quantified wrote: post #8

I wholeheartedly agree with the majority of this. In my experience “REST” has been like a religion in which hardly anyone either read the founding text or bothered to interpret very much of it. Fielding’s thesis does not require all of what adherents have claimed it does. An API does not a priori need to adhere to any sect of “REST”, though for many use cases it will benefit. For example, a machine-to-machine API mig…

> This API is not intended for UI usage, so why not do this? There are HTTP clients that are incapable of sending a request body with a GET request, because the original HTTP/1.1 RFC [1] says that a client must not send a request body in a GET request. This has changed with newer RFCs, but 2616-compliant clients still exist. If you're going to do this, you need to support POST as well, to accommodate those clients. I…

Conceptually clearer HTTP methods is another valid direction to consider. Of course, the farther we wander from hypermedia, the farther we wander from the HT part of HTTP. At some point we recognize that HTTP became popular because firewalls let port 80 and port 443 traffic in and we have code-level APIs to do work, we just try to make our work look like it’s hypertext.

Re: Should we rebrand REST?

#154

Post by Spivak » Sun, May 30, 2021, 2:37 AM UTC

incrudible wrote: post #125

andrewmcwatters wrote: post #104

This is all pedantry. I don't think I've ever talked to a developer who cares. All people care about is whether or not you have a sane API to work with over HTTP. It uses appropriate verbs, maybe, and has meaningful endpoints and request and response objects you work with, hopefully. You can make up a new acronym for it like "WNI" or Web Negotiation Interface, but it doesn't change anything that people care about. Th…

> It uses appropriate verbs... This shouldn't even be a thing to think about. HTTP verbs and error codes don't map well to many real use cases. You might argue that "GET" does map well to a query. However, you can't send a body with a GET, so you need to put that information in the URL, which is limited and causes other issues to consider. If we just admit that we're really doing RPC anyway, there is no point in usin…

So not only do they not map cleanly to actual applications but if you intermix your app's request statuses and error codes you don't have any way to distinguish an error in your application with an error in your transport.

Does a 400 response mean that your HTTP is malformed or the that the app specific request payload is malformed? Depends on the app...