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

Richardson Maturity Model

martinfowler.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: Richardson Maturity Model

#21

Post by hbrn »

schnable wrote: post #14
raverbashing wrote: post #6

I'll say that the religious approach some take with REST is weird to me. Apparently there's some promised utopia behind getting REST perfect but in the end, nobody does it right but everybody makes it work for their case Getting the linkrels back is great, but it is up to your frontend to interpret them and display them back. There is no "magic" there because only humans know what does cancel/change mean, not the com…

It's a fair point, but there is value in having those URLs constructed by the server rather than the client. The server can shift the path and params to make changes without the client having to make updates.

No, there's illusion of value:

1. Paths are changed extremely rarely. Optimizing architecture for something that happens once a year is not a good idea. The cost of changing paths manually is pretty much always lower than the cost of HATEOAS.

2. You still want redirects from the old paths, because clients keep old paths in memory until refresh (which you don't control).

3. Typically when paths are changed, it also affects the entry point, so client still needs to be updated.

Re: Richardson Maturity Model

#22

Post by commandlinefan »

JimDabell wrote: post #5

Calling an API without hypermedia a “level two REST API” is like calling a lettuce and tomato sandwich a “level two BLT”. You’re missing an intrinsic piece of the puzzle and anybody actually expecting a BLT is going to be disappointed. Why are people so adamant that they absolutely must call non-REST APIs “REST”? Names are free, you don’t have to hijack the name of something else!

> they absolutely must call non-REST APIs “REST”

What would you call it though? If the only thing we call REST is what's called a "level 3 REST" API in this article, then virtually nothing would be called REST.

Re: Richardson Maturity Model

#23

Post by hbrn »

JimDabell wrote: post #5

Calling an API without hypermedia a “level two REST API” is like calling a lettuce and tomato sandwich a “level two BLT”. You’re missing an intrinsic piece of the puzzle and anybody actually expecting a BLT is going to be disappointed. Why are people so adamant that they absolutely must call non-REST APIs “REST”? Names are free, you don’t have to hijack the name of something else!

Because 99% of REST value is coming from structuring your API around Resources and Verbs.

HATEOAS is for snake oil sellers and their religious followers, who want to feel superior.

Re: Richardson Maturity Model

#24

Post by hbrn »

JimDabell wrote: post #20
marcosdumay wrote: post #18

Earlier quoted context omitted.

Nobody ever understood what REST means. The "standard" creator choosing not to document its meaning really didn't help. So, yeah, REST means whatever people use it for, that is 'HTTP services with JSON payload'. That's the actually valuable part of it anyway, the meaning that was documented after everybody started using it wrong is a synonym for the web, and we already have a name for it.

> The "standard" creator choosing not to document its meaning really didn't help. REST isn’t a standard, it’s an architectural style. And I’m not sure how you can say that the author chose not to document its meaning when the name “REST” originated with the author’s PhD dissertation.

Fielding's dissertation was about WWW. It turns out that 20+ years later, there's a new portion of WWW (web APIs) where hypermedia is not that useful.

One big difference is that WWW clients are browsers, which you don't develop yourself. API clients are typically developed by the same team that builds the API.

Losing interoperability is detrimental for WWW (browser wars), but turns out when you are the consumer of your own API, interoperability is not important at all.

Re: Richardson Maturity Model

#25

Post by schnable »

hbrn wrote: post #21
schnable wrote: post #14

Earlier quoted context omitted.

It's a fair point, but there is value in having those URLs constructed by the server rather than the client. The server can shift the path and params to make changes without the client having to make updates.

No, there's illusion of value: 1. Paths are changed extremely rarely. Optimizing architecture for something that happens once a year is not a good idea. The cost of changing paths manually is pretty much always lower than the cost of HATEOAS. 2. You still want redirects from the old paths, because clients keep old paths in memory until refresh (which you don't control). 3. Typically when paths are changed, it also af…

It depends on your use case. I have resolved critical bugs for mobile apps quickly server side using HATEOS by doing things that sticking extra parameters on a URL or rerouting traffic. The alternative would be updating multiple clients, QAing them, and getting them through app store reviews. If the clients aren't within your control even that isn't possible.

Re: Richardson Maturity Model

#26

Post by kelseyfrog »

hbrn wrote: post #23
JimDabell wrote: post #5

Calling an API without hypermedia a “level two REST API” is like calling a lettuce and tomato sandwich a “level two BLT”. You’re missing an intrinsic piece of the puzzle and anybody actually expecting a BLT is going to be disappointed. Why are people so adamant that they absolutely must call non-REST APIs “REST”? Names are free, you don’t have to hijack the name of something else!

Because 99% of REST value is coming from structuring your API around Resources and Verbs. HATEOAS is for snake oil sellers and their religious followers, who want to feel superior.

Having developed both HATEOAS and non-HATEOAS systems. The HATEOAS systems were categorically less brittle, easier to change, and had faster turn around times. The immediate benefits of resources and verbs in greenfield development are easy to spot, but ongoing system evolution is where HATEOAS's value prop shines.

Re: Richardson Maturity Model

#27

Post by hbrn »

schnable wrote: post #25
hbrn wrote: post #21

Earlier quoted context omitted.

No, there's illusion of value: 1. Paths are changed extremely rarely. Optimizing architecture for something that happens once a year is not a good idea. The cost of changing paths manually is pretty much always lower than the cost of HATEOAS. 2. You still want redirects from the old paths, because clients keep old paths in memory until refresh (which you don't control). 3. Typically when paths are changed, it also af…

It depends on your use case. I have resolved critical bugs for mobile apps quickly server side using HATEOS by doing things that sticking extra parameters on a URL or rerouting traffic. The alternative would be updating multiple clients, QAing them, and getting them through app store reviews. If the clients aren't within your control even that isn't possible.

Sure, HATEOAS can be useful when you don't have control over clients or over the routes.

Which is exactly the case for WWW: clients are browsers (not developed by you), and URLs can be images from another server (not owned by you).

And while it can happen for APIs, those cases are exception rather than the rule. That's why it's so annoying when REST purists are trying to shame people who are actually doing the right thing.

I would also be curious to learn how exactly sticking extra params would fix a critical bug. I can't help but wonder if bugs were caused by HATEOAS in the first place.

Re: Richardson Maturity Model

#28

Post by pan69 »

kelseyfrog wrote: post #26
hbrn wrote: post #23

Earlier quoted context omitted.

Because 99% of REST value is coming from structuring your API around Resources and Verbs. HATEOAS is for snake oil sellers and their religious followers, who want to feel superior.

Having developed both HATEOAS and non-HATEOAS systems. The HATEOAS systems were categorically less brittle, easier to change, and had faster turn around times. The immediate benefits of resources and verbs in greenfield development are easy to spot, but ongoing system evolution is where HATEOAS's value prop shines.

With HATEOAS, are you just not pushing complexity of change into the client/consumer?

Re: Richardson Maturity Model

#29

Post by kelseyfrog »

pan69 wrote: post #28
kelseyfrog wrote: post #26

Earlier quoted context omitted.

Having developed both HATEOAS and non-HATEOAS systems. The HATEOAS systems were categorically less brittle, easier to change, and had faster turn around times. The immediate benefits of resources and verbs in greenfield development are easy to spot, but ongoing system evolution is where HATEOAS's value prop shines.

With HATEOAS, are you just not pushing complexity of change into the client/consumer?

It's a common misconception that complexity is a zero-sum game.

There are gains to be made from certain design decisions and HATEOAS in my experience with multiple front end teams and multiple back end teams working in HATEOAS-land is that the HATEOAS systems were able to address ongoing systems evolution in ways that when complexity did come up, it was easier to address and manage.

I'm not here to proposition it as a silver bullet, or have quantitative data to substantiate it, but in my experience the ease of ongoing system architectural evolution in both client and server realms made up for the difference in tension between the two camps.

One example of a tension in HATEOAS is the complaint from clients that they can't hardcode links like they did before. One of the points, obviously, of HATEOAS is the ability to represent state using hypermedia[links]. One terrible thing the backend could do is make clients traverse multiple resources to get a url to perform an action elsewhere[1].

Rather than saying "tough luck, deal with it," communication workflows and architecture was adjusted so that for most workflows, the required urls were made available as a natural part of accessing resources needed to accomplish the workflow.

Does this require some work on the client to extract the link and use it for the next step in the workflow? yes. Do the other benefits make up for it? It did in my org. It might in yours. Part of being a good architect is making that decision correctly more often than not.

1. I'm being a bit loose with terminology, but I hope it helps rather than detracts from understanding.

Re: Richardson Maturity Model

#30

Post by Isognoviastoma »

commandlinefan wrote: post #22
JimDabell wrote: post #5

Calling an API without hypermedia a “level two REST API” is like calling a lettuce and tomato sandwich a “level two BLT”. You’re missing an intrinsic piece of the puzzle and anybody actually expecting a BLT is going to be disappointed. Why are people so adamant that they absolutely must call non-REST APIs “REST”? Names are free, you don’t have to hijack the name of something else!

> they absolutely must call non-REST APIs “REST” What would you call it though? If the only thing we call REST is what's called a "level 3 REST" API in this article, then virtually nothing would be called REST.

Call it "JSON API", that pinpoints all important characteristics of most "REST" APIs lacking HATEOAS.
Post reply on HN