5 ms·

I thought just the opposite. I was pleasantly surprised to see that it looks pretty in line with Fielding's thesis. What are you objecting to?

by bct 13y ago

masklinn 13y ago
* Primary focus on URI structure (to the point where the third thing explained is that you can access each resource from multiple URIs… after the URI being customizable and the URI pattern & mapping to CRUD operations). That there are links is only "documented" at #6. * Very little on document structure: only mentioned in examples, no overview let alone more precise documentation, there seems to be 5 or 6 possible _link keys but none is defined further than the examples showing it exists. Notes that the entry point will be disabled if links are disabled, said entry point's media type is not documented and only defined as "a list of links to accessible resources". * Very limited linking (only tree traversal/reads), no support at all for resource alteration information in documents, how a resource is created, modified or deleted is solely out-of-band knowledge. No state transition is available to a RESTful Eve client, it is limited to a readonly interface. * Same for non-trivial fetching, e.g. filter and search * What little linking there is, is optional (!) * No custom content types, no media types documentation * And the official documentation generation extension documents (verb, URI) pairs: http://blog.python-eve.org/eve-docs http://blog.python-eve.org/eve-docs, what little data documentation there is is subservient to the creation (verb, URI) pair, and is the expected payload... I rest my case, Eve only puts "emphasis on REST" in the "REST as a meaningless buzzword" sense, no other understanding matches the reality of the documentation. edit: don't get me wrong, if you want to build a "random stuff over HTTP" or "RPC over HTTP" or "Ad-hoc over HTTP" API it's fine. If it works for you (or does not, I don't really care) nobody's going to mind. Just stop fucking lying about what it is.
- dtauzell 13y ago
  Can you point to some examples of REST apis that show what this is missing?
- reinhardt 13y ago
  Not necessarily disagreeing but can you point to any real-world REST-as-Master-Fielding-intended API to convince the sceptical among us it's not just an academic exercise (PhD thesis even) or wishful thinking, akin to the Semantic Web or Strong AI?
  - bct 13y ago
    http://www.ietf.org/rfc/rfc5023.txt http://www.ietf.org/rfc/rfc5023.txt There's no need to be sarcastic.
- bct 13y ago
  I think you're being too hard on it. It's difficult for me to see how a general-purpose library could cover many of those things. Could it go further, and do a better job of encouraging people to use REST? Sure. But it's trying to be pragmatic, and right now we're dealing with a world where people think that their unwillingness to learn is an argument against an architectural style.

I thought just the opposite. I was pleasantly surprised to see that it looks pretty in line with Fielding's thesis. What are you objecting to?

by bct 13y ago

I thought just the opposite. I was pleasantly surprised to see that it looks pretty in line with Fielding's thesis. What are you objecting to?

masklinn 13y ago

* Primary focus on URI structure (to the point where the third thing explained is that you can access each resource from multiple URIs… after the URI being customizable and the URI pattern & mapping to CRUD operations). That there are links is only "documented" at #6. * Very little on document structure: only mentioned in examples, no overview let alone more precise documentation, there seems to be 5 or 6 possible _link keys but none is defined further than the examples showing it exists. Notes that the entry point will be disabled if links are disabled, said entry point's media type is not documented and only defined as "a list of links to accessible resources". * Very limited linking (only tree traversal/reads), no support at all for resource alteration information in documents, how a resource is created, modified or deleted is solely out-of-band knowledge. No state transition is available to a RESTful Eve client, it is limited to a readonly interface. * Same for non-trivial fetching, e.g. filter and search * What little linking there is, is optional (!) * No custom content types, no media types documentation * And the official documentation generation extension documents (verb, URI) pairs: http://blog.python-eve.org/eve-docs http://blog.python-eve.org/eve-docs, what little data documentation there is is subservient to the creation (verb, URI) pair, and is the expected payload... I rest my case, Eve only puts "emphasis on REST" in the "REST as a meaningless buzzword" sense, no other understanding matches the reality of the documentation. edit: don't get me wrong, if you want to build a "random stuff over HTTP" or "RPC over HTTP" or "Ad-hoc over HTTP" API it's fine. If it works for you (or does not, I don't really care) nobody's going to mind. Just stop fucking lying about what it is.

dtauzell 13y ago
Can you point to some examples of REST apis that show what this is missing?
reinhardt 13y ago
Not necessarily disagreeing but can you point to any real-world REST-as-Master-Fielding-intended API to convince the sceptical among us it's not just an academic exercise (PhD thesis even) or wishful thinking, akin to the Semantic Web or Strong AI?
- bct 13y ago
  http://www.ietf.org/rfc/rfc5023.txt http://www.ietf.org/rfc/rfc5023.txt There's no need to be sarcastic.
bct 13y ago
I think you're being too hard on it. It's difficult for me to see how a general-purpose library could cover many of those things. Could it go further, and do a better job of encouraging people to use REST? Sure. But it's trying to be pragmatic, and right now we're dealing with a world where people think that their unwillingness to learn is an argument against an architectural style.