Eve looks nice, but they really need to justify not supporting PUT, beyond just “PATCH is usually better”.

If you want to allow "/people/12345" to be accessed at "/people/johnson" or even "/johnson", it seems Flask routing would make that trivial. I don't think Eve itself has to care. [EDIT: even so, I see now that "/people/johnson" is possible through "custom item endpoints".]

By the way, I might be in love with this framework.

Example definition of a resource:

    class JobList(resty.ResourceList):
        model = models.Job
        deep = dict(disciplines=dict(drawings=None))
        query_options = subqueryload_all('disciplines.drawings')

http://tastypieapi.org/

Specifically: http://spyne.io/#s=sql&ser=Json&show=Data

Not knocking the tools, they're great + fun. But writing the glue gets non-trivial fast once you step beyond a single table with no access control.

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

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.

There's no need to be sarcastic.