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

51–60 of 154 posts

Re: Should we rebrand REST?

#51

Post by goto11 »

Joker_vD wrote: post #50
goto11 wrote: post #43

Earlier quoted context omitted.

What is the problem with hard-coded URLs? It is certainly simpler than having to extract the URLs from some other request. If they don't change (and they shouldn't!) I don't see the problem.

Well the problem is exactly that they do change sometimes. And having only one hard-coded URL is easier than having twelve of those. > It is certainly simpler than having to extract the URLs from some other request. It's not extracted from other request, it's extracted from the response to the original request, and using a field from the local struct is not harder than using a global constant.

> Well the problem is exactly that they do change sometimes.

Well they shouldn't! And if the API arbitrarily changes URLs around without reason, then surely they might also change the URL for the initial request.

Re: Should we rebrand REST?

#52

Post by Joker_vD »

goto11 wrote: post #51
Joker_vD wrote: post #50

Earlier quoted context omitted.

Well the problem is exactly that they do change sometimes. And having only one hard-coded URL is easier than having twelve of those. > It is certainly simpler than having to extract the URLs from some other request. It's not extracted from other request, it's extracted from the response to the original request, and using a field from the local struct is not harder than using a global constant.

> Well the problem is exactly that they do change sometimes. Well they shouldn't! And if the API arbitrarily changes URLs around without reason, then surely they might also change the URL for the initial request.

> Well they shouldn't!

If you treat them as public interface, they shouldn't, yes. But if you treat them as internal implementation details, they absolutely could.

One can also think about it as static vs dynamic dispatch: you make an initial request, you get a vtable of "method name -> method pointer" as a part of response. Or you can hardcode the method pointers and make it the remote server's job to properly chose the appropriate internal endpoint.

Re: Should we rebrand REST?

#53

Post by slver »

goto11 wrote: post #21
slver wrote: post #16

Earlier quoted context omitted.

> in my opinion this not only introduces more confusion I don't think that's possible. I've officially banned the word "REST" from being used in technical discussions. Using that word is not just useless, it's harmful. Note that this is not an issue with the original paper, but everything that happened after it.

The problem is not REST per se, the problem is people thinking a machine-to-machine API "should" conform to REST. I have not seen a coherent argument for why HATEOAS should be a useful property for API's beside "REST says so". That said, we should not throw the baby out with the bathwater. Some REST principles like statelessness are good design for API's also.

You're entirely right.

Another problem with REST is that Fielding himself describes it as a "large grain resource approach".

It's no surprise we love HTTP and URLs when we have to return, say, images, downloads or entire documents in our APIs. Just put the URL in, serve it on your CDN.

But for small grain data items, it's terrible.

Re: Should we rebrand REST?

#54

Post by goto11 »

Joker_vD wrote: post #52
goto11 wrote: post #51

Earlier quoted context omitted.

> Well the problem is exactly that they do change sometimes. Well they shouldn't! And if the API arbitrarily changes URLs around without reason, then surely they might also change the URL for the initial request.

> Well they shouldn't! If you treat them as public interface, they shouldn't, yes. But if you treat them as internal implementation details, they absolutely could. One can also think about it as static vs dynamic dispatch: you make an initial request, you get a vtable of "method name -> method pointer" as a part of response. Or you can hardcode the method pointers and make it the remote server's job to properly chose…

But what is the point? Why introduce an extra layer of complexity to mitigate changing URL's, something which has no purpose in the first place?

Re: Should we rebrand REST?

#55

Post by slver »

unscaled wrote: post #47
slver wrote: post #45

Earlier quoted context omitted.

To be fair, you need at least one hard-coded URL in your client, don't you? To hit the root entrypoint. And if you have one hard-coded URL... and use it as the root of other URLs, then it's no hard to support than anything. URLs are useful in REST because the API often crosses domain boundaries and company boundaries. One site links to another and so on. Most APIs are not like that. In fact they're only like that whe…

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 Verbs) of the Richardson Maturity model, but I've never felt convinced that HATEOAS is worth the effort. It seems like the majority of HTTP API designers out there have the same opinion.

The "maturity model" is honestly non-sense and Fielding also thinks that.

It's kinda like first level to being a bird is flapping your hands, second step is whistling with your mouth... No, you're not any closer to being a bird, you need to be the entire thing for the benefits of being a bird to come about.

Trying to stick to the CRUD concept of HTTP verbs is rather harmful. CRUD is a common starting point for a domain's verb structure, but being restricted to it is crippling and results in bizarre obscure semantics or underdeveloped business constraints.

I'd say to hell with all of it. I stick to HTTP as-is, and that's it. Also it's telling I think that to this day HTML forms only support GET and POST. Even HTML isn't RESTful I guess. /s

Re: Should we rebrand REST?

#56

Post by slver »

deaddodo wrote: post #38
EMM_386 wrote: post #30

Earlier quoted context omitted.

> I don't think that's possible. I've officially banned the word "REST" from being used in technical discussions. I've been a software engineer for decades and I am helping a company move from SOAP-based XML services into a more coherent REST-type architecture. Why would this be a banned technical discussion?

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.

Re: Should we rebrand REST?

#57

Post by einrealist »

pa7x1 wrote: post #37
goto11 wrote: post #21

Earlier quoted context omitted.

The problem is not REST per se, the problem is people thinking a machine-to-machine API "should" conform to REST. I have not seen a coherent argument for why HATEOAS should be a useful property for API's beside "REST says so". That said, we should not throw the baby out with the bathwater. Some REST principles like statelessness are good design for API's also.

100% agree, HATEOAS is rather useless for machine-to-machine. And it shouldn't come as a surprise that most APIs decide to not commit to this design constraint. I prefer to think of real-world APIs as coming in varying degees of RESTfulness depending on the design constraints they have chosen to conform to. Good engineering is about making judicious analysis of the trade-offs involved, if HATEOAS doesn't bring you an…

I disagree. Even if an API is effectively used by a machine, the root cause either is human interaction or it makes sense to also allow human interaction (e.g. for testing, troubleshooting, interactive documentation). HATEOAS can help to define formats that solve both problems.

Re: Should we rebrand REST?

#58

Post by Communitivity »

"there's just far too much confusion about what REST means to rescue it"

No, there is no confusing. REST is exactly what's in Roy Fielding's thesis. Anything as is derived from REST, often with dismal ends. RESTful, RESTlike, RESTish are weasel words designed to say something along the lines of 'It's REST, but with these additions', or 'It's REST, but with these constraints loosened', or a mix of both.

I was there at the beginning of SOA in 2004 and SOA then was an amazingly useful concept that worked well. The term SOA was hijacked to mean so many things, often by consultants pitching their version of SOA enablement or training, and at a rapid pace. By 2009 the meaning of SOA was so buzzwordy and clouded that people were trying to invent new terms to refer to the original concept.

If someone wants to create a new thing, create a new thing and give attribution to the shoulders you stand on (i.e., ABC is based on REST but is different in these ways..1,2,3).

Re: Should we rebrand REST?

#59

Post by cryptos »

kuu wrote: post #2

TLDR: REST != web service APIs

That is exactly the point! Most people talking about "REST" are just talking about web service APIs or HTTP APIs, because they are not aware of the actual meaning. REST became a shallow term.

Re: Should we rebrand REST?

#60

Post by bewo001 »

deaddodo wrote: post #38
EMM_386 wrote: post #30

Earlier quoted context omitted.

> I don't think that's possible. I've officially banned the word "REST" from being used in technical discussions. I've been a software engineer for decades and I am helping a company move from SOAP-based XML services into a more coherent REST-type architecture. Why would this be a banned technical discussion?

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…

They call REST anything that uses JSON over HTTP nowadays. What I don't get, when they don't know or don't want to do REST, why they are not just calling their API JSON/HTTP?
Post reply on HN