Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



> 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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: