Agreed in principle, but there's an implementation issue that many common
HTTP libraries will only do POST/GET, not PUT/DELETE, so need url versions
of 'UD' anyway.
Wow, you guys have really thought about it :) This problem more manifests itself in enterprise firewalls and proxies but agreed, support for all the HTTP verbs is sadly limited. That's exactly what the X-HTTP-Method-Override header was invented for.
Perhaps the compromise position is to work both ways:
POST/GET/PUT/DELETE /<object> accepts all 4 CRUD operations
POST /<object>/set alternative form of 'U' (if cannot PUT)
POST /<object>/destroy alternative form of 'D' (if cannot DELETE)
POST /<object>/create alternative form of 'C' (for symmetry)
GET /<object>/info alternative form of 'R' (for symmetry)
I'd be more inclined to go with one or the other, and in case it's not obvious yet I've got my sights set on the myriad
Google GData clients (Java, .NET, PHP, Python, Objective-C and Javascript, all under Apache licensing), and of course the army of developers who are already familiar with their APIs.
> Non-CRUD operations such as start, stop, restart, clone, snapshot, etc.
> can be exposed by "actuator" URLs, which fits nicely with HATEOAS.
The actuator URLs for these can then fit in alongside the alternative
actuator forms of the CRUD operations themselves.
Right, the format for the URLs should be specified too, but the client can tell what methods to expose based on which are present (thus saving the user from pushing buttons that are guaranteed to result in errors, like "start"ing an abstract template or "stop"ping a stopped machine).
Sam