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