3 ms·

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 wo

• masklinn 16y ago
  > 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.
  • nikcub 16y 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_style.htm#sec_5_2_2 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