I was wondering, I can’t come up with any other function that a “normal” dynamic website would have, that can’t be reduced down either a create, read, update or delete function. No matter what is done on the site, it ends up being one of these functions. I mean, it is the basis of HTTP too, right? GET = read. PUT = update/create, POST = create/update, DELETE = delete.
Is this thinking too simplistic? Can an HTTP request be ambiguous at all? I don’t think so. But, I’d love to hear any other thoughts.
Your thinking seems to be correct for the majority of cases but as it usually happens in life there are exceptions to the rule. For example, there can be combinations of those, one request would be doing two things at a time. It is not uncommon to have POST doing some modifications on the server and at the same time retrieving information to be displayed or fetched. In some cases this is not good practice but sometimes I allow this - for example, a POST request to save a form which ended up with invalid input data - the POST request may re-display the form for the user to correct.
And there can also be actions that do not fall into any of the 4 request methods. For example, “SEND” - submitting a form sends the message somewhere - it doesn’t update or create anything, it sends. Of course, there can be a mixture of sending and storing in the db but the the very action of sending doesn’t fall into any of these categories for me.
There could be many more request methods outside these 4 if you think outside the realm of a web application: SHUTDOWN, RESTART, SLEEP, SHUT_THE_DOOR, TURN_ON_THE_LIGHTS, PLAY_MUSIC, FLUSH_THE_TOILET, DETONATE_THE_BOMB or whatever you imagine a computer accepting http requests were able to do.
I would say for general web applications such exceptions are rare. But we need to keep in mind that sometimes a http request might have to do something different that any one of these 4. I’ve read that it’s possible to invent any request method and use it with XMLHTTP but I’ve never tested it.
To me, the examples of “actions” above should all fall under update.
I can’t think of a point in time, when a request can do two things at once. You can have a web page doing a lot of things, but the requests to the server still fall into one of the CRUD functions. Even a “send” is some form of update in some way. I am also not talking strictly from a database perspective, but rather purely from a functional perspective between the web server and the client.
I think this is a grey area where people will disagree. To me turning an appliance on or off is pretty far from updating anything, even sending - what is sending updating? I think this is stretching things a little bit too far. Of course, in the case of current http implementation you would have to do this because you have no other choice but if we weren’t restricted in the choice of request types I wouldn’t call them updates - and I wouldn’t see why I would need to treat them as updates considering how far they are from an update-type action.
Of course, in the web world most of actions will fall into these more easily: posting a comment, creating an account, deleting a user, uploading a photo, etc.
But, with the web, even if you have a switch that is “connected”, if you want to turn it on or off, you are updating the controller of the switch with a command. Update->on, update->off. Or, if you consider the switch a resource according to HTTP and it is called “switch”, you would have /switch/off and /switch/on and send it under a post method. Wouldn’t that work?
Well, in this case you are right if by turning something on or off you mean updating the state of the switch - then this is like controlling a flag in the database and this would fall into the category of updating. But I was talking about different kind of methods - by switching on/off I meant initiating one-time actions just like “flush the toilet” or “launch rocket” - you fire up a command and initiate some action (you tell a computer or a robot to do something) - in such a system there is no on and off switch to update.
To me the current distinction between POST and PUT is too blurry with the GET and DELETE being fairly clear. I think this is not enough to cover the needs of all web applications in a consistent manner. Of course, you can categorize actions for your application and assign them to the request methods the way that makes sense to you and it will work but I don’t think it’s a good idea to make general rules about the available request methods for all to follow.
What would be the best request method for a service which takes a file uploaded by a user, converts in to another format and returns it in the same request? Would it be PUT because you are updating your own file with the remote service? Or POST because you are using the service to create a new file in a way? To me GET would make more sense because the primary reason for me is to get the file in a desired format and the fact that it is created from my own upload is a secondary matter - similar to requesting a search result page whose content depends on the query I first send in the GET request (sure, this is purely theoretical because we know size limitations of GET wouldn’t allow us to use it for uploads anyway). This is all too fuzzy and blurry.
Personally, I feel it’s best to stick with the traditional GET/POST duality - GET for all cases where we need to only fetch data and POST for all cases when we intend to affect the system in any way - be it create, update, delete, or cause any other action to happen, like send, shut down, restart, launch, etc. At least the boundaries are pretty clear cut and unambiguous. Not to mention the limitations of current browsers which won’t process forms with PUT or DELETE (using XMLHTTP is not a good enough workaround for me).
The definition definitely leaves room for different interpretations. However, it all ends up defined in the application. That is my point. For any application, the “actions” that are so common now in PHP frameworks all boil down to a CRUD function.
This is certainly possible, but then we must send along extra information to the server for it to know which type of write command is necessary. Oh, and theoretically, we could reduce everything down to a read or write.
To be honest, I didn’t realize there was this limitation in HTML forms. Now I do. Thanks!
As we move forward into the future, I feel standard web pages are going to be rarer and rarer. More and more will be done client side and communication will be more and more asynchronous, because of the amount of data being sent. Still, no matter what the requesting format is, because of the client/ server basis, all requests to the server can be reduced to some form of CRUD.
… all requests to the server can be reduced to some form of CRUD.
Perhaps that is true in the same sense that living organisms can be reduced to organs, then cells, then cell constituents → molecules → atoms → sub-atomic particles → elementary particles.
But is that useful in terms of what applications actually do? Maybe it depends on the app’s domain of action, its vocabulary, its data or process model.
If an app deals primarily with structured data then it may be useful to break every page down to a CRUD type; then you might be able to build the app as a collection of forms with some kind of form builder. That might be useful because it might assist design, development and implementation.
But if an app deals with unstructured, textual or binary data, then a CRUD model might not fit. In terms of what the app does, maybe its pages are better conceived as actions on things that make sense and have meaning in the domain of action. In that case trying to break it down to CRUD types may hinder development, not help it.
My point is that I think it is usually better to imagine, design and develop apps in terms of the ‘natural’ concepts and elements in their own domain of action, rather than necessarily trying to reduce them to a minimal set of simplistic types. Then we could deal with the app on its own terms, and importantly we would be speaking a common language with the customers and end users, and that would really help development.
I think I’m siding with Lemon Juice on this point. Maybe compound actions might break down to CRUD elements in any case, but maybe not; and I think it might be better to keep an open mind about it depending on the case at hand.
I can see what you are getting at and I understand it completely. I’d like to throw in some other thinking.
I am coming from a framework kind of perspective and with a framework, there are two “domains” a client needs to understand. Their own problem domain (why they need to program an application in the first place) and the domain of the framework’s problems, (i.e. getting an application, the client’s actual problem domain, to work).
I feel current frameworks just don’t split apart the two domains well. They intermingle them badly actually. The client has a router system, controller classes, model classes and sub-systems and view classes/ templates, etc… These are all framework domain problems, which are needed to solve the client’s domain problem.
What if we can reduce the framework domain down to just models and views and give the client the stipulation, you have to fit your model logic into either a read (through the view), or with an update, create or delete. Oh, and a page always has some single object. Those are the only stipulations. We have now simplified the client’s need to understand the frameworks domain logic down to two areas of the framework. Granted, this sounds too simplistic, but it is something I believe can work, and work well.
In the reduced framework domain I mentioned above, there is also a parameter setup, where requests are formulated properly to match the domain problem. It will be similar to what routers do. But, we aren’t routing to a controller. We are just setting up parameters for the application (the model and view) to work right.
