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

101–110 of 154 posts

Re: Should we rebrand REST?

#101

Post by GauntletWizard »

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

I'm a normalization anti - I believe that many normalized tables are an antipattern and that likes are better stored not as their own table but as a list within the comment row - And I still believe that `PUT /like` is the right pattern to use, and that likes should be thought of as their own resource in a RESTful way.

Re: Should we rebrand REST?

#102

Post by crubier »

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 GraphQL already. It’s actually simple, I promise! Self documenting, introspectable, supports so much code generation and validation tools, etc...

I know I’ll get downvoted for saying this, the HN crowd thinks « GraphQL = complicated » for some reason.

Re: Should we rebrand REST?

#103

Post by jpdb »

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.

Re: Should we rebrand REST?

#104

Post by andrewmcwatters »

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.

There are bigger problems in the world. No need to keep redefining dirt.

If you spend a considerable amount of time pondering such things, it's probably a sign that you need to be growing somewhere else in life and using those skills to enhance your existing ones.

Have tires really changed that much in 200 years?

Re: Should we rebrand REST?

#105

Post by andrewmcwatters »

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…

GraphQL is inherently more complicated. It's one more step at a minimum, and more honestly two or three more steps.

I can build an endpoint and point it straight to a parameterized SQL query.

With GraphQL, I build an endpoint, and point it straight to a GraphQL... schema? And then I have to define where that data comes from, and then how to return it...

It's just professional negligence to suggest it's not more involved.

Re: Should we rebrand REST?

#106

Post by mybrid »

It has been my experience that most programming terms end up being business or marketing driven if they gain much traction. My pet peeve at one time is API. This term contains the word "interface", meaning external code will interface with your code. However, business calls everything an API and it means a unit of software work from their perspective. Probably the goofiest one is AI. When people say they are using AI it doesn't tell me anything. What is a VM? Python, Perl and other interpreted languages are said to run in a VM. Isn't a container a VM? A container is just host OS VM. I remember when VMWare only had host OS VMs until they came out with the Hypervisor VM, ESXi. Docker is a brand of container and both are VMs. The point is that it is human nature that any word that becomes popularized will take on business and marketing purposes. You just have to roll with it unless one is expressly carrying out technical communication, then clarity of definition does matter.

Re: Should we rebrand REST?

#107

Post by unscaled »

slver wrote: post #55
unscaled wrote: post #47

Earlier quoted context omitted.

If you look at the hydra API example[1] linked by OP, this is exactly what it needs: one entrypoint URL. If your API only needs a single domain name (as over 99% of the APIs are), clients can just have the base URL encoded in a constant or a configuration file. 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 sch…

> 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 system as a system which implement the following constraints:

1. Follows a Client-Server model

2. Is Stateless (request-response model)

3. Indicates cacheability of responses

4. Has Uniform Interface defined by the following restrictions:

Identification of resources (URIs); Manipulation of resources through representations (media types); Self-descriptive messages; Hypermedia as the engine of application state (HATEOAS)

5. Isolates access to non-adjacent layers

6. (Optional) Supports code on demand.

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.

The half-assed "RESTful APIs" of today implement only a subset of the constraints listed above. They are always client-serves, stateless, isolate access to non-adjacent layers and implement two of the uniform interface restrictions (URIs and manipulation of resources through representations). Sometimes they also indicate cacheability. However, they do not support HATEOAS (including most of the level 3 wannabes), code-on-demand and most importantly self-describing messages.

The lack of the constraints above means our modern APIs cannot achieve some of the benefits the web browser does: most notably flexibility and open-ended evolution. But they do have some other benefits over traditional RPC systems.

I think the maturity model itself is quite useless, but the following properties are useful:

1. Correct HTTP verbs: Differentiating between PUT and POST will let your intermediaries know when the request can be retried. 2. URIs uniquely identify resources: beyond the obvious benefit (cachability), it allows for easy sharding, distribution and smart redirection by any intermediary server.

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.

Re: Should we rebrand REST?

#108

Post by Udik »

geodel wrote: post #70
fmakunbound wrote: post #68

No, it does not deserve a rebrand. It owns the ecosystem of shit that it brought about over the last two decades. I cannot tell you how many meetings I've sat through where engineers have wasted time on discussing the RESTiness of a given "API" call, or which verb makes the most sense. Anyway, we're only a couple of years of group think away from adopting something like JSON-RPC and then it's welcome back to 1999 for…

Excellent point. It is like I said for Facebook is great for me in sense all folks who I have no interest in contacting are gathered at one place. So now I can avoid all in one simple way. > I cannot tell you how many meetings I've sat through where engineers have wasted time... We have similar REST experts who are making everyone else's life hell.

Oh yes, the best were those who seriously claimed, in my company, that actual endpoints should have been random UUIDs. Because, you know, you must get there only through "discoverability" and hypermedia links.

Re: Should we rebrand REST?

#109

Post by alephu5 »

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…

REST will be rebranded one day because our industry loves renaming old ideas and presenting them as new.

I agree with you though, it's pointless.

Re: Should we rebrand REST?

#110

Post by graftak »

ajuc wrote: post #87
mixmastamyk wrote: post #72

Earlier quoted context omitted.

Say the two phrases out loud and the reason becomes obvious. The second doesn’t exactly roll off the tongue.

JSON API would be my preferred name.

Somehow someone thought it’s a good idea to name a spec JSON:API[1] which is a ton of fun in search engines. The spec itself is quite alright though and it makes requests rather predictable.

https://jsonapi.org/

Post reply on HN