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.
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.
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?
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 ), 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”.
Whatever the URI is, it's still going to be a sub-resource of some collection, right? That's the only way of defining how to stuff it into the DB. I didn't see any way of defining schemata for "one-off" top-level resources. Since these resources are just members of collections, I don't see the problem with using internally-generated identifiers for them.
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.
