[asalahli]

> the original/popular definitions were so incredibly abstract and disconnected from real life usage that they ended up being whatever the person implementing it wanted it to be.

This is what happened with REST too, and it frustrates me more than it probably should.

The original pattern is such a good idea and not even remotely abstract. It's a well defined architectural pattern for a well defined problem yet people still managed to bastardize it to the point that the term REST barely means anything today

[rendall]

Unfortunately, Fielding's dissertation itself alone gives inadequate guidance to construct or even fully identify a REST API, and so a over the subsequent years a mishmash of sometimes contradictory blog posts, discussion forums, militancy, angry flame wars, and books fleshed out the REST.

The 2007 book RESTful Web Services was wildly influential in popularizing the standard by clarifying and presenting a set of further guidelines or constraints that it called Resource-Oriented Architecture.

[LegionMammal978]

As far as I can tell, he's not even describing an "API" as we'd normally use the term today. For all practical purposes, it's pretty much just "using an HTTP server and hyperlinks to let (human) users discover and interact with resources". (Or replace "HTTP" with another protocol like it in all but name.) If it has any structure past that, then it's not REST in his sense.

Personally, I think "API" is an unclear term for that kind of structure. The only actual interfacing is the HTTP protocol between the server and web browser. But the browser traditionally only acts as a proxy for the user, who is the one being served access to the resources.

[whstl]

> As far as I can tell, he's not even describing an "API" as we'd normally use the term today. For all practical purposes, it's pretty much just "using an HTTP server and hyperlinks to let (human) users discover and interact with resources".

Bingo.

Like Monads, it mostly later interpretations missing the mark.

[maleldil]

How does this relate to monads? They have a proper definition of the signatures required and the laws they must obey.

[whstl]

I said “Later interpretations of Monads”, I did not say “monads”.

Fielding’s dissertation is fine in itself. The web itself, AtomPub, OData, among others, all follow REST and HATEOAS.

Same for Monads: the laws are fine and the implementation in Haskell is fine, but meme tutorials and later implementations miss the mark.

[whstl]

This is another good example. I remember people getting very angry here 10-15 years ago over HATEOAS.

In most discussions REST has come to mean “cute URLs” thanks to Rails.

[mcny]

I don't know who is to blame for this -- I think it should be the entire team, not just the developer for every time I click a link from a message somewhere on my phone and a website opens which opens an app and it says "congratulations, you have performed this operation (that isn't idempotent)". Like ok, but why are you doing stuff with a get action... Shouldn't you prompt people to ask in the app hey I am about to do something, do you want me to?

[Pamar]

What about "microservice", then?

[whstl]

This is perhaps a case where miscommunication saved an entire industry.

I once got a new hire from Uber and for months on end his complaint was that “the services are too big”.

[mcny]

I once wrote a small class at work and by the time I left it was like over 8k lines long. People jokes it was my fault I called it HelperUtil instead of something more descriptive. It was a dumping ground for all the stuff people didn't want to think about. I wonder if something like that is possible in the microservice world?

[mattmanser]

It probably wasn't a joke. If you call something HelperUtil, it will become a dumping ground. That's a learnable lesson around naming, a mistake, but it's not learnable if it keeps getting described as a joke.

C# accidentally solved this problem with extension methods, these little helper utils at least get grouped by type and not in one humongous file. Or maybe that was part of the design team's intention behind them all along.

And because they're static you can easily see when services or state are getting passed into a method, clearly showing when it should in fact be some sort of service or a new type.

[XajniN]

You’ve never seen `public static class Extensions` in a project named Something.Shared?

[whstl]

In the microservices world this is the monolith itself sitting in the center :/

Even in architectures that start as distributed, I’ve seen the “involuntary monolith” arising.

Way too common, unfortunately.

[ssdspoimdsjvv]

Of course, it just becomes the HelperUtilService!

[pjmlp]

Same thing, a typical OS has tons of microservices talking over OS IPC.

Sun RPC was microservices.

But understanding they are several decades old concept isn't cool, doesn't sell conference tickets, books and consulting training.

[lmm]

> The original pattern is such a good idea and not even remotely abstract. It's a well defined architectural pattern for a well defined problem yet people still managed to bastardize it to the point that the term REST barely means anything today

The original pattern is extremely abstract and a bad idea. There has been precisely one successful implementation of the original REST "pattern", the web, and only because the pattern was retrofitted onto it; most of the things in REST-as-originally-defined are bad ideas, as any apples-to-apples comparison will show.

I get oppositely frustrated because "REST" was adopted as a rallying cry for one or two good ideas (fitting your protocol to the GET/POST and 2xx/4xx/5xx distinctions from HTTP instead of treating it as a completely opaque transport layer; not wrapping everything in oodles of XML) and the term brought along a lot of bad ideas as baggage. But the meaning of the term shifted towards doing the things that are good because the original meaning was bad.