

Eve: A Python REST API Framework - m0th87
http://python-eve.org/index.html

======
jdp
Leaving PUT out might be a mistake. The rationale from the slide deck is sound
but the framework neglects the case in which you are creating a resource with
a known identifier. The POST verb is good for when you don't know the
identifier, and want to leave it up to the handler to generate one for you.
You could just define the same semantics for POST as for PUT, but that breaks
the spec in that a resource created by POST should be subordinate to the
requested resource.

~~~
gruntmaster9000
They give a good rationale for supporting PATCH, but not for omitting PUT. Not
supporting PUT is absolutely a mistake, especially with a schema-less backend.
Being unable to PUT means being unable to set a property as undefined (by
PUTting a complete version of the resource without that property). The usual
approach with PATCH is to set it to None/null, but then the property is still
defined as None instead of removed. (Or, some APIs will remove a property with
a None value, but then it is undefined instead of being set to None.) A small
but potentially important semantic distinction.

~~~
jessaustin
Does this corner case really justify dealing with another entire verb? Even if
we stipulate that _null_ has a specific meaning for our application that we
don't want to screw up, how about empty object, array, or string? ( _{}_ ,
_[]_ , or _" "_ ) Do _all_ of those mean something for, e.g., the "lastname"
field?

~~~
gruntmaster9000
PUT is almost functionally identical to a PATCH, so it’s not exactly an entire
other verb. It’s also a very standard verb. Using the example from a pull
request on Eve (
[https://github.com/nicolaiarocci/eve/issues/96](https://github.com/nicolaiarocci/eve/issues/96)
), what if you want to indicate that the middle name is no longer known?
Marking it as null means there isn’t one, not that it is unknown. Sure, for
many applications the distinction doesn’t matter. But for plenty, it does. (I
just recently had to fix an API’s implementation of PUT that actually was more
like a PATCH but needed to be a proper PUT.) And it’s foolish for an API to
require knowing a nonstandard way of expressing `undefined` when simply _not
defining_ something is the best way to not define it.

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

~~~
nicola
Hello, thanks for your feedback. PUT is coming to Eve with v0.1.0 (next
release).

~~~
nicola
In fact, it's on the dev branch already.

------
aidos
Interesting. I've just completed a library to run on Flask. Actually, it's an
extension of flask_restful that allows for arbitrary nested resources, control
over fields exposed the whole way down the tree etc. PUT/POST of deeply nested
objects. I built it because I'm using SQLAlchemy and nothing quite supported
how I wanted to do it. I've also used the helpers from flask_restless (with a
bunch of modifications) to help with the loading / saving of SQLAlchemy object
trees.

Example definition of a resource:

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

I know have a really easy to configure api that plays very nicely with
Restangular. It's very simple - totally not rest complete, but sufficient for
my needs.

------
noelherrick
A simple REST api framework for Python is something I've been looking for, and
this definitely fits the bill. Unfortunately, I need to use it with Postgres.
For those who also have this requirement, it looks like they have a SQLAlchemy
development branch that enables support for relational databases. Looks
promising!

~~~
jhh
Using Flask, SQLAlchemy what is it that you are missing?

~~~
kennywinker
Writing the glue takes a surprising amount of time/energy/learning for a newb.
I've got a couple of hobby projects on the go where I am learning to create
webapps / rest apis using flask + SQLAlchemy. None of these projects are
anywhere near shippable.

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.

------
masklinn
And as usual, this is REST-as-a-buzzword, not REST-as-REpresentational-State-
Transfer.

~~~
bct
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
* 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.

~~~
reinhardt
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
[http://www.ietf.org/rfc/rfc5023.txt](http://www.ietf.org/rfc/rfc5023.txt)

There's no need to be sarcastic.

------
njharman
:( Did anyone else expect this to be about EVE Online?

~~~
thejosh
EVE has really good community APIs & toys (such as the market place firehose,
not sure if that's still around), I guess the developers who play it need
something to do when they are mining ;-).

------
rpedela
Under the hood, is this API event-based, thread-based, or both?

~~~
jessaustin
Under the hood, it's Flask, so it's WSGI. WSGI can be served in a variety of
ways.

------
the1
does it generate documentation for all link relations, media types, and
available resources in workspace?

~~~
nicola
Hello, there's a third party tool called Eve-Docs [http://blog.python-
eve.org/eve-docs](http://blog.python-eve.org/eve-docs). It is a work in
progress, and looks promising.

------
Shish2k
Disappointed that this is not the much-awaited REST API for EVE online (a game
written in python)...

~~~
orng
I totally thought this would be a third party CREST-like (CREST is what the
EVE online REST API is called. The 'C' is for 'Carbon') hack of some sorts.

