I am doing a one-way data transfer app from MS Access to a Rails app. I keep the Rails app restful, so I tell my colleague that the Access app needs to keep track of whether or not a record is already sent over to the Rails app because the Access app will need the ID of that record in the Rails app to do “update”. He doubted it was necessary as, if, for example, Access sends a record to the Rails Person model with the Access app’s person model ID, let’s call it AID, so if the Rails app “sees” incoming “:name => ‘John Doe’, :aid => 123”, and finds no such Person model with ‘AID’ equal to 123, then Rails should just create it, and when it does find a Person model with ‘AID’ equal to 123, then update it.
I told him that the design is restful and it is a ‘good thing’ to keep two separate calls (one with post and one with put); the one with ‘put’ needs the ID of the record which the call is about to update.
But he has some good point, why do we differentiate create and update but not merge it in one method in which a check of whether or not the record is already there can determine if it’ll be a creation or an update?
Thank You!
While in many cases you might not need to care about the difference, Create and Update are fundamentally different concepts.
There are many cases it would be fatal to blindly update (and thus overwrite) a record, when a Create would have failed because a duplicate id was found.
If that is not the case with your app, and never will be in the future, I’d say it might actually be fine to merge create and update – or perhaps keep the create and update mehods but provide a 3. api which does does both.