Sketching out a read+write REST-friendly CMA

The current Fedora Content Model Architecture (CMA) achieves two great feats:

1. Describes the physical characteristics of objects in a given model.  Currently, this comprises an enumeration of required Datastreams and their properties (e.g. datastream ID, mime type, format URI).  This is entirely new in Fedora 3.0.
2. Enumerates a set of fedora-mediated services available for all objects in given model, and binds these services to their implementation.  Prior to Fedora 3.0, these services (and their bindings) were explicitly enumerated in each and every every object instance. 

Here, we are concerned with #2.  As they exist now, services in Fedora have the following basic mental model:

result = object + sDef + method + parameters.

where result is a stream of bytes, object is the identity (pid) of an object, sDef is the identiyu (pid) of a Service Definition object, method is the name of an operation enumerated in sDef, and parameters are a series of constrained key/value pairs. In reality, the two means by which these may be invoked are via API-A and API-A-Lite.

In API-A, using SOAP:
getDissemination(object, sDef, method, parameters)

and in API-A-Lite, using HTTP GET:
http://fedora.base/get/\{object}/{sdef}/{method}?{parameters}

There is no way to interact with services in the current REST/HTTP API

The AtomPub thought experiment provides one compellng example for a fully read-write CMA-based service framework, and specifically focuses an HTTP+REST mode of interaction - something which is currently not supported in Fedora.  From the AtomPub example, we see a few obvious features that are missing:

1. The ability to use HTTP methods beyond 'GET'
2. The ability to process HTTP headers (eg. the Slug: header in AtomPub)
3. The ability to return specific HTTP headers in the response (e.g. ETags)

Can these features be added to Fedora's APIs without violating the current service mental model?  Do these features have to exist within the current mental model at all? 

1. There is no way to distinguish idempotent from safe from unsafe operations in the current model
   1. Up until now, service operations have been assumed to be safe and idempotent. A read+write API will invalidate that assumption
2. HTTP methods are different from methods in the service model
   1. Mapping HTTP methods to method parameters is technically possible, but seems less than ideal. For example, POST map to parameter http.method=post
3. HTTP headers, as inputs, are not directly supported
   1. Mapping HTTP headers to input parameters is technically possible. For example, Slug: XYZ may map to Slug=XYZ
4. Passing headers from the SDep impl to the response is currently not possible

(to be continued)