snax

Such drama in Rails-land !

the tangly roots of CRUD

Think about the beginning of the web. Berners-Lee’s original idea was that the web would be a readable and writable space from within the browser. Because of this, we have the GET, PUT, and DELETE HTTP methods, as well as POST, which is slightly less straightforward.

Since Hansson’s address at Railsconf, these have been widely noted as rough equivalents to the create, read, update, delete object manipulation paradigm.

However, it is useful to notice that create is just as legitimately mapped to PUT as it is to POST, depending on circumstances. In RFC 2616, PUT is described as creating or updating a resource at the given URI, while POST is described as creating a resource at a subordinate URI, if a resource is created at all. That is, if you already know what you want the identifier to be (for example, a permalink) for the object you want to create, a PUT-based create is more appropriate than a POST-based one.

CRUD does not span multiple models

In Rails, though, because practically every database record requires an RDBMS-generated non-semantic primary key, PUT creates are ruled out of hand, at least if the organization of the record’s object model is equivalent to the organization of the record as expressed in the user’s view. So basically, Rails forces creates to be POSTs, but the operation remains constrained within a single object model.

It is very important to notice something here: no method of CRUD spans multiple models.

CRUD, HTTP, and relational databases all operate similar to a filesystem. The client requests a resource, performs some transformation on it, and returns some resource (possibly the same resource) to the server. The server itself does not perform transformations on the resource, not ever ever. (WebDAV is the more fully realized extension of the HTTP-as-filesystem approach.)

search is not a resource

But if the server never updates the resource on its own, what’s the point of a controller, besides authentication? Well, there isn’t one, really. You can get away with this constrained method of interaction in many consumer web apps, because however complicated your data model, your application may still be basically views on the database.

But sometimes, the server will want to perform some transformations on existing data based on conditions supplied by the user. This is where CRUD breaks down. Search is an example of this. Search is not a resource, it is an operation.

no meta-operations in CRUD

There is no “perform operation X on resource Y” method in CRUD, or in a database, or in a filesystem. There is in HTTP, but it is free-form: it is POST. POST does not give you any help as to how to specify which operation, which resource, or which conditions. The web-as-read/write model, by design, does not take into account server-side operations on resources; after all, that’s up to the server.

So if you really want to follow CRUD exactly, even if you don’t span multiple models, all operations on a resource, instead of about a resource, must take place on the client side.

what would CRUD search look like?

There are many good reasons to instantiate your searches as objects, but trying to conform to CRUD is not one of them. A true CRUD search would be for the client to request every resource, and then look through them on its own. This avoids server-side manipulation of the data.

Searches can not be treated as simple reads in most domains, even if the content of the read is generated on the fly, because many searches are relative to the client (think Google personalized search). A URI for a single resource should not return non-same-identity result contents depending on who the requester is. Maybe multiple levels of access, perhaps, but not entirely different resources.

Even if you instantiate your search requests, you also need to receive back search results. If search results are part of the request object, then under CRUD the client shouldn’t have had to ask for them in the first place—it should have known them already. After all, no server-side operations on data. But if search results are a separate model, then how, under CRUD, can the client request them? Under CRUD/HTTP, the client is disallowed from creating an object of type A and receiving as a response an object of type B. There is no clear way (in my mind, at least) to guarantee that such a method would be idempotent, and if it takes place over PUT, which it might, it must be.

So, the client would have to know the URI that the requests will appear at. But if it knows that already, why did it have to submit a request in the first place? Forcing the client to wait around for some unspecified delay and telling it to hope that the results will have magically appeared at the target URI by then is not really an acceptable solution, programmatically.

other things inappropriate for CRUD

I think part of the confusion over this is related to Rails’ target domain. As mentioned above (and in some of the comments on Coda’s entry), consumer web apps do not need many server-side operations, whether on a single resource, or across multiple resources. It is easy to think of exceptions, though. Consider a Flickr-like application that allows the client to crop an image or adjust contrast. Should the client be forced to read the image, perform the cpu-intensive operation client-side (in Javascript most likely), and then update it back to the server? No, of course not. But should the client be required to create a “crop object” and submit that to the server, where from then on (unless the client deletes it) that particular crop will be accessible from a never-changing global URI? No, that’s ridiculous. Crop, like search, is an operation, not a resource.

conclusion

In my bioinformatics projects, the most frequent tasks are transformations of extant records into other types of records. In fact, the client never creates new records on its own, instead only performs operations on old records. The results of those operations, though, may become new records. CRUD is hardly ever appropriate for this situation.

I think, too, that part of my distrust of CRUD is related to my distrust of the command pattern. For me, at least, implementing and using the command pattern is rarely worth the trouble, because it can’t cleanly handle operations spanning multiple classes.

That’s all.

August 20, 2007

7 comments

Comments are closed.