4 ms·

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

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

geodel 5y ago
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.
- deleted 5y ago
  [deleted]
- Udik 5y ago
  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.
kag0 5y ago
> 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.
- mmcdermott 5y ago
  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 5y ago
    [deleted]
shashurup 5y ago
And then another couple of hours wasted discussing encoding some complex query into url parameters. On the other hand it was a good lesson to avoid such discussions in the future using any feasible excuse.

geodel 5y ago

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.

deleted 5y ago
[deleted]
Udik 5y ago
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.

kag0 5y ago

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

mmcdermott 5y ago
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 5y ago
  [deleted]

shashurup 5y ago

And then another couple of hours wasted discussing encoding some complex query into url parameters. On the other hand it was a good lesson to avoid such discussions in the future using any feasible excuse.