title: differentiate create and update of named resource in REST
body: <p>I've read <a href="https://stackoverflow.com/questions/630453/put-vs-post-in-rest">put-vs-post-in-rest</a> through, and I know that PUT is for create and update specific resource with identifier given specifically in URL.</p>
  
  <p>But if I'm going to strict the "update" operation with If-Match (which means user MUST provide valid ETag to update the resource), given that PUT is also used to create named resource, (which do not require If-Match), then the API will have to guess whether the PUT request means to update or to create by whether If-Match header is provided.</p>
  
  <p>I know this can be done but I think it's weird. Are there other (more reasonable) ways to do this (by not using PUT maybe)?</p>
  
  <p>Thanks.</p>
  
  <p><strong>UPDATE:</strong></p>
  
  <p>Here is my scenario for now:</p>
  
  <pre><code># create the resource the first time
  curl -X PUT -d '{"foo": "bar"}' /resource/r_id 
  
  # the resource already exists, so this will fail with a 4xx error
  curl -X PUT -d '{"foo": "bar2"}' /resource/r_id 
  
  # must provide valid If-Match to make updates work
  curl -X PUT -H 'If-Modefied: myetag' -d '{"foo": "bar2"}'  /resource/r_id
  
  # what makes it confusing is this:
  # user want to make a new record, but /resource/r_id2 in fact exists
  # the API will return an error message, should it be
  # "creation failed -- already exist" or "update failed -- ETag not provided"?
  curl -X PUT -d '{"foo": "bar"}' /resource/r_id2
  </code></pre>
  
  <p>It's not that this can't be done, it's just that I think this design(with PUT for both ETag-controlled update AND named creation) might be confusing, I personally think it's better if I use different vocabulary (not just PUT), but, I'm here asking what's the reasonable and RESTful way I can do this.</p>