Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should we rebrand REST?

kieranpotts.com

Post reply on HN
Print view View original

121–130 of 154 posts

Re: Should we rebrand REST?

#121

Post by crubier »

jpdb wrote: post #103
crubier wrote: post #102

I’ve been in GraphQL land for 4-5 years now, and all these discussions about restfulness, Http and other details make me cringe. It feels like watching apes fighting about whether the cylinder goes in the triangle or star-shaped hole. It does not fit! Realize this and move on! Unless your company is only about CRUD (with no JOINs), the Rest model is severely limited or mismatched to your business domain. Just use Gra…

I've liked GraphQL the few times I've used it, but I think the standard way of doing pagination with `node`s and `edge`s makes me feel less like I'm working with my data and more some odd abstraction. I think if I used GraphQL more I could get over it, but that aspect always makes me wish for just a bit more.

What you are talking about is the Relay specification, not GraphQL.

Relay is completely optional and only a way to optimize performance of client side stuff.

Here is how you deal with lists in normal GraphQL:

        type Query {
            projects(first: Int): [Project!]!
        }

        type Project {
            id:        Int
            name:      String
        }

Re: Should we rebrand REST?

#123

Post by fooyc »

conradludgate wrote: post #96
fooyc wrote: post #85

Earlier quoted context omitted.

Most business can in a convoluted way. But should you they? Take HN as an example. People can upvote comments. Should you represent the action of upvoting as a resource creation, in a REST way ? Or as an action ? Take Amazon, how do you represent the action of putting a cart item aside ? The action of paying ? The action of changing which card is the default one ?

> People can upvote comments. Should you represent the action of upvoting as a resource creation, in a REST way ? Maybe yes. Likes are a relationship between a User and a Post/Comment. In a standard normalised relational db model, they would have their own table. So `PUT /like` would add a Like to that table

But should you design your API like a data store ? That's my whole point actually.

Do you design anemic domain models, or models that represent just data without any kind of logic ? If yes, I guess REST is ok as well.

Re: Should we rebrand REST?

#124

Post by fooyc »

SahAssar wrote: post #97
fooyc wrote: post #95

Earlier quoted context omitted.

Indeed you can interpret my comment like that, so I will rephrase it in an other way: REST represents everything as a resources and the creation, update, and retrieval of resources. Unless your business is fundamentally about storage without any kind of associated logic, REST will be a bad design choice. Why limit yourself to 4 verbs ? This is insane. Your business has more semantics than create, read, update, delete…

I think we're talking about slightly different things. I'm using REST as an interface to a storage (of blobs/objects/whatever), just like you would SQL SELECT, UPDATE, INSERT, DELETE. I then add more things that listens to changes to that storage, so the data is sortof the API. You're talking about putting the API layer upfront so you'd have a REBASE verb in the same layer that we have GET/POST or SELECT/INSERT etc.…

> I'm using REST as an interface to a storage > I then add more things that listens to changes to that storage, so the data is sortof the API.

I get it, but that's exactly the issue.

Data changes are a lossy way to represent business actions/intents.

Why would you represent your service as a storage ? Is your business about data storage ? If not, that's the wrong abstraction.

What's the advantage of this ?

> You're talking about putting the API layer upfront so you'd have a REBASE verb in the same layer that we have GET/POST or SELECT/INSERT etc.

I would definitely _not_ do that.

Separation of concerns tells me to not mix the transport layer with other concerns. HTTP is just a transport, business semantics have nothing to do in this layer.

Re: Should we rebrand REST?

#125

Post by incrudible »

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 using any other verb than "POST", passing in the arguments via the body, and returning any other codes than 200 and 400 with the result (or error) in the response. If we use JSON for this (as we likely already do), you have JSON-RPC.

> 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.

I actually care about it. The word REST forces us to think about irrelevant things, such as whether something should be a PUT or a POST, which error code maps best to an exception - only to end up with an API that is more annoying to implement, document and use.

We would do well to transition out of of this insanity driven by buzzword compliance. If we managed to transition out of XML, we can do this too.

> Have tires really changed that much in 200 years?

Yes, they have!

https://en.wikipedia.org/wiki/Tire#History

Re: Should we rebrand REST?

#126

Post by Kinrany »

scrumper wrote: post #77

This is interesting, and I broadly agree with Kieran's complaints about the quasi-REST-lite that passes for web APIs today. Sadly there's not much tooling or guidance around to try and encourage people to do REST properly. It's really not done well at migrating out of academia, as the author points out, and that's starting to look like a missed opportunity for industry. Other comments here seem to tacitly accept that…

Can you generate a client library for that?

Re: Should we rebrand REST?

#127

Post by incrudible »

unscaled wrote: post #107
slver wrote: post #55

Earlier quoted context omitted.

> What HATEOAS ostensibly gives you is not the ability to painlessly switch domains, but rather to change your entire URL path structure and even the entire schema represented by your REST endpoints. Which would be utterly pointless, because the fact this schema is opaque to the clients means that it's meaningless to the clients. So you have no reason to change it. > I've always worked all my API up to level 2 (HTTP…

While Level 3, as currently implemented by some APIs, is a cargo-culted version of Fielding's idea of HATEOAS, Level 1 and 2 of the model have some usefulness for some types of APIs. What you get by implementing what is called a "RESTful API" nowadays is something that is very different from the original concept of REST, but is still useful to some applications, over plain RPC. Let's unpack it. Fielding RESTful syste…

> Applying all the restrictions stated above, lets you immense benefits: for instance cacheability, stateless and uniform resource identification make your system easy to distribute and scale to handle large amount of traffic; self-describing messages, manipulation of resources through representations and code-on-demand let you have a system that can evolve gracefully without requiring a big bang protocol upgrade.

Suppose that you wanted or needed any or all of these things: REST doesn't give these things to you for free. If REST was a standard that people actually followed, as opposed to an almost meaningless buzzword, maybe you'd get some of these things for free. The original REST paper doesn't specify any of these things to a degree where they would "just work". If it did, it would be a standard so complex, nobody would implement it properly.

> With traditional HTTP-RPC (even with a standardized protocol like gRPC or SOAP), your intermediary has to be fully aware of the RPC schema to cache or know when it can retry. If you want to add a sharding gateway you need to especially develop a customized solution. A Level 2 "RESTful API" still has all these benefits.

The only thing you're reasonably going be able to cache through a "dumb" intermediary are GETs for static or rarely changing resources. You don't have to handle these through RPC, you can use plain HTTP handlers for that, you don't need to go "full REST".

Re: Should we rebrand REST?

#128

Post by motogpjimbo »

conradludgate wrote: post #96
fooyc wrote: post #85

Earlier quoted context omitted.

Most business can in a convoluted way. But should you they? Take HN as an example. People can upvote comments. Should you represent the action of upvoting as a resource creation, in a REST way ? Or as an action ? Take Amazon, how do you represent the action of putting a cart item aside ? The action of paying ? The action of changing which card is the default one ?

> People can upvote comments. Should you represent the action of upvoting as a resource creation, in a REST way ? Maybe yes. Likes are a relationship between a User and a Post/Comment. In a standard normalised relational db model, they would have their own table. So `PUT /like` would add a Like to that table

How is saying "I like a comment by adding a like to the list of likes" better than just saying "I like this comment"? I genuinely don't understand why REST advocates think it's a good idea to divorce an application's data model from its business logic, as if the business logic is a minor implementation detail that can be ignored.

HN allows users to like comments. All it needs is a `/like-comment` endpoint that you pass a comment ID to. Anything else is pointless mental masturbation.

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

Re: Should we rebrand REST?

#129

Post by andrewmcwatters »

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…

As soon as you ignore HTTP constructs, you drop infrastructural benefits and the benefits of particular levels of abstraction reacting to those responses, which are often fully intended to be used.

You can’t get frustrated that HTTP isn’t a raw socket.

If you didn’t care about any of that you might as well use websockets for everything. And then as soon as you do, you lose out on everything that requires an HTTP request/response.

You end up rebuilding things that already exist. It’s a waste of time.

Re: Should we rebrand REST?

#130

Post by bborud »

nicaragua wrote: post #122
bborud wrote: post #65

HTTP API is awkward to pronounce. Why not call it Web API?

At least "HTTP API" has some sort of context. Web APIs can be anything from data transmission, media capturing, rendering, cryptography, etc.

Fair points, but "HTTP API" still isn't a good name.
Post reply on HN