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.
I suppose but json is the least important part of the “spec.”
Should we rebrand REST?
91–100 of 154 posts
Re: Should we rebrand REST?
#92No, 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…
> which verb makes the most sense I think that's a valid discussion. Each method has specific semantics in the HTTP spec, and consumers of an API (both automated and human) will expect you to follow them. For example, I expect to be able to retry a PUT request without much concern. But if I'm not able to do that then that's a problem that would have been worth a discussion.
I think the problem with REST is that these kinds of semantics discussions are helpful _if_ you go all in. Frankly, I've never seen anything more than toy apps that went all in. Most of the world wants JSON-RPC and is bending towards REST to be "correct." I suspect that giving in to RPC would be cleaner overall.
Until we build proper RPC composition (via lightweight monads, I'm sure) and let that sweep the world.
Re: Should we rebrand REST?
#93REST is largely over-hyped as an API design. REST fundamentally represents data transfers. No business can be modeled purely as data transfers. CRUD API would be a good name.
It is not overhyped at all. It is misunderstood. If you pick an API stack, consider your users. If you build an API for general consumption that you want to gradually evolve and that should remain valid years from now, a RESTful API with HATEOS is a great choice. If you need to drive a UI from your API and you control that UI, use something that makes you more productive and can be easily changed on both ends quickly…
> It is not overhyped at all. It is misunderstood.
How many times have I heard that...
Re: Should we rebrand REST?
#94REST is largely over-hyped as an API design. REST fundamentally represents data transfers. No business can be modeled purely as data transfers. CRUD API would be a good name.
I'm pretty sure netflix, spotify, notion, airtable, github and many others can be modeled as pretty pure data transfers. What am I missing? What internet-based service is not using data transfer as its base for building services on top of?
Re: Should we rebrand REST?
#95REST is largely over-hyped as an API design. REST fundamentally represents data transfers. No business can be modeled purely as data transfers. CRUD API would be a good name.
I'm pretty sure netflix, spotify, notion, airtable, github and many others can be modeled as pretty pure data transfers. What am I missing? What internet-based service is not using data transfer as its base for building services on top of?
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.
Git has commit, rebase, branch, tag, revert, amend, clone, and so has GitHub. A good API will represent these actions as actions and not as a convoluted mess of resource creations or updates.
There is an impedance mismatch between REST and most businesses, like there is an impedance mismatch between an ORM and a relational database.
Re: Should we rebrand REST?
#96Earlier quoted context omitted.
It is not overhyped at all. It is misunderstood. If you pick an API stack, consider your users. If you build an API for general consumption that you want to gradually evolve and that should remain valid years from now, a RESTful API with HATEOS is a great choice. If you need to drive a UI from your API and you control that UI, use something that makes you more productive and can be easily changed on both ends quickly…
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
Re: Should we rebrand REST?
#97Earlier quoted context omitted.
I'm pretty sure netflix, spotify, notion, airtable, github and many others can be modeled as pretty pure data transfers. What am I missing? What internet-based service is not using data transfer as its base for building services on top of?
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.
Your example of git easily abstracts on my view since it already does those basic operations, but not on yours since you'd need a separate REBASE verb and so on as a part of the protocol.
I think we just have different expectations of the protocol.
Re: Should we rebrand REST?
#98Earlier quoted context omitted.
> which verb makes the most sense I think that's a valid discussion. Each method has specific semantics in the HTTP spec, and consumers of an API (both automated and human) will expect you to follow them. For example, I expect to be able to retry a PUT request without much concern. But if I'm not able to do that then that's a problem that would have been worth a discussion.
I think the problem with REST is that these kinds of semantics discussions are helpful _if_ you go all in. Frankly, I've never seen anything more than toy apps that went all in. Most of the world wants JSON-RPC and is bending towards REST to be "correct." I suspect that giving in to RPC would be cleaner overall. Until we build proper RPC composition (via lightweight monads, I'm sure) and let that sweep the world.
[deleted]
Re: Should we rebrand REST?
#99Earlier quoted context omitted.
I think their point is that REST means nothing beyond “uses HTTP verbs” these days. Most companies/teams can’t even agree on the differences between POST, PUT and PATCH; let alone status codes, payload structure, authentication, etc. So using the term REST will mean something different to every person using it. Similar to how a Ruby, PHP and Python engineer will envision a different architecture if you tell them to b…
> I think their point is that REST means nothing beyond “uses HTTP verbs” Funny thing is that this means HTML pages also aren't restful, because they stick to GET and POST.
HTML (/browsers) have agreed upon payloads, status codes and authentication. The lack of PUT/DELETE/etc is more a function of use cases than the HTTP/HTML standard and there are plenty of example servers that are fully RESTful. That was also the original use case of web browsers (as a document-store/multimedia+hyperlink-enhanced FTP).
Re: Should we rebrand REST?
#100> Client applications would not need to be hard-coded with any domain-specific knowledge of the server-side APIs they interact with. Instead, they would discover all the available resources and operations dynamically, at runtime. A client application developed for one hypermedia API could be easily forked and modified for another hypermedia-driven web service. And "smart clients", which are capable of consuming any hypermedia API with a common grammar, could become a reality.
This is WSDL and WADL, basically, except there's no common grammar to render a usable interface. The only real thing like what is described is a browser.
If you want a universal interface, you make a web app, and the browser is the universal UI. Otherwise you just make a crappy console app and a crappy custom protocol using a HTTP API (or if you hate compatibility, simplicity and convenience: gRPC).
To answer the poster's question, no, we're not going to rebrand REST. There are tons of improperly used terms that have been around for ages, they do not get rebranded. You just have to make a new thing and give it a new name and hope that it too isn't misused. ("DevOps" is the most glaring example to me, but also add "hacker", "crypto", "web", "cloud", "container", etc)