undefined | Better HN

0 pointsnikcub15y ago0 comments

well I believe both are not correct.

the idea is that you can build a generic 'REST' client and point it to almost anything that is a 'REST API' and it will work, in the same way we can now with web browsers

a REST client will never figure out /api/1/ - which is why resources go in the path and query parameters go in as, well, query parameters :)

from the server side you are right that modern front controllers and routing can make it all the same (heck, I can route resources to different subdomains, if I want), but a proxy does not know what the front controller logic is (ie. working backwards to what part is what).

0 comments

2 comments · 1 top-level

masklinn15y ago· 1 in thread

> the idea is that you can build a generic 'REST' client and point it to almost anything that is a 'REST API' and it will work, in the same way we can now with web browsers

That's a stupid idea. REST is built on two things: content types and resource location. The content types indicate the meaning and location of the resources, if the client does not understand the content-type, it can not do anything.

You can not "build a generic 'REST' client and point it to almost anything that is a 'REST API' and it will work", that makes no sense. Indeed, that's not what web browsers do: the driver of the API on a website is the user, not the browser.

> a REST client will never figure out /api/1/ - which is why resources go in the path and query parameters go in as, well, query parameters :)

That's completely irrelevant.

nikcubOP15y ago

> That's a stupid idea. REST is built on two things: content types and resource location.

here is what my generic REST client looks like:

* HTTP[s] * JSON * Atom and RSS * Caching layer

some controller login in between all of these. I inherit this to implement simple models and controllers in the client and just tell it which resources I want (like fields in a database)

how is that not a generic client?

for twitter I have classes called users and statuses, with each method defined. for google I have similar classes. this all took minutes for me to get working - I thought that was the entire point of REST?

read the original desertion, sec. 5.2.2 connectors:

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...

> if the client does not understand the content-type, it can not do anything.

generic doesn't mean understanding the payload, it means understanding the protocol

j / k navigate · click thread line to collapse