CODEWITHSUNDEEP
rest
Nik So
Nik So

Reputation: 16811

why restful design means to differentiate create and update?

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!

Upvotes: 4

Views: 488

Answers (3)

Lotus Notes
Lotus Notes

Reputation: 6363

A more thorough description was given at the following link concerning POST vs. PUT:

http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/

In SQL analogy, POST is an INSERT with an automatically generated primary key, and PUT is an INSERT that specifies the primary key in the INSERT statement.

The difference would probably be irrelevant if all your primary keys are auto-generated. The differentiation is there for those who do wish for the client to be able to choose the primary key, for example if it is not simply an integer (perhaps a GUID or text identifier).

Upvotes: 3

mlathe
mlathe

Reputation: 2385

I agree with your colleague. Ultimately services should be easy to use and do the hard work for the caller. Forcing the caller to remember whether a create or update is needed is annoying.

As i see it in order for him to know whether to call Create or Update would mean he would need to either

  1. keep track whether he called Create already (which means you can't remove the record in the Rails app without telling him)
  2. he needs to ask the Rails app whether the data is already in the system, and then call the right API.

Both options suck.

One other thing to add. That doesn't mean your service has to always first check if the record already exists. If expect your usage to be skewed heavily for one operation (ie updates happen often but insert are seldom), then it probably makes sense to "assume the record is there and do an Update, if it fails b/c the record isn't there, then do an Insert".

Upvotes: 2

leeeroy
leeeroy

Reputation: 11446

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.

Upvotes: 0

Related Questions