6

Possible Duplicate:
PUT vs POST in REST

I know this has been discussed a lot and although I kind of get it, I don't completely get it. I think if someone could answer this in relation to the following example it would make it easy to understand.

Create new user - add a new user to a database sending Username, Password, Email. PUT or POST?

I think maybe PUT as I don't want to have duplicate users and PUT is like deleting and replacing. However, I have checks that avoid a user being added twice so maybe I should use POST?

Update user - change email or password. PUT or POST?

I could use URI api/update/my_username and then send new email via the body so should this be PUT? I could also send it all in the URI e.g. api/update/my_username/email/new_email@email.com

Community
  • 1
  • 1
Paul Benbow
  • 329
  • 2
  • 11
  • 22

2 Answers2

11

Create - POST, update - PUT, delete - DELETE.

For better understanding of HTTP Verbs usage look at RFC https://www.rfc-editor.org/rfc/rfc2616

Also PUT request can create entities but then response code should be 201 created instead 200 OK and 204 No Content. But it's up to you either allow/implement such behaviour or not.

Community
  • 1
  • 1
Regfor
  • 8,515
  • 1
  • 38
  • 51
  • I don't think it matters much whether the email is in the body or the uri, at least not in terms of security. If you can read headers, you can read the body. – Vala Jul 19 '12 at 11:06
  • On first reading about REST I decided Create - POST, update - PUT, delete - DELETE but it doesn't seem to be that simple. http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/ – Paul Benbow Jul 19 '12 at 11:48
  • @Paul Benbow yes, it's not so simple, there are nuances, that's why I've attached link to RFC ( all nuances are described there), but Post, put, delete, get are good, in most cases, mapping to CRUD operations. And there is no need to look for harder ways. – Regfor Jul 19 '12 at 12:14
  • @Thor84no yes it doesn't matter but when emails are going in URI, even with HTTPS it's possible to sniff them – Regfor Jul 19 '12 at 12:31
  • @Regfor No, that's not how HTTPS works. HTTPS encrypts (using SSL/TLS) the *entire* HTTP protocol, this includes the URI, which is the first line of an HTTP request. See http://stackoverflow.com/questions/499591/are-https-urls-encrypted for more details. – Vala Jul 19 '12 at 13:27
  • @Thor84no you are right about URI and HTTPS – Regfor Jul 19 '12 at 13:37
  • @Regfor So, assuming I don't send any data via the URI and it all goes in the Body. If I create a unique new user I should use PUT rather than POST? – Paul Benbow Jul 19 '12 at 13:44
  • 1
    No email in Uri is not related to main question. So one more time: post - create, when you have no id for entity, put - update, when you have entity and id, but it can create nested entities. – Regfor Jul 19 '12 at 13:53
2

The key guide is whether the operation is idempotent, i.e., what happens if you repeat it. If the same thing overall happens (ignoring logs, last change times, and other fripperies) whether you do the request once, twice or 20 times, it is idempotent and should be a PUT. If the number of times you do it matters, use POST.

Creation is often non-idempotent because you typically issue the user an ID, but it doesn't have to be like that (e.g., if the caller specifies the ID). Updating is often idempotent as changing data fields to their current values is often an effective no-op in practice.

Donal Fellows
  • 133,037
  • 18
  • 149
  • 215
  • "The key guide is whether the operation is idempotent" - It I POST to create a new user but put rules in to stop duplicate emails and usernames then it becomes idempotent because of the rules doesn't it? – Paul Benbow Jul 19 '12 at 11:49
  • If you have rules that stop duplicate emails etc. violations of those rules should change the outcome. On the first CREATE you should get a new entity created and a 200 OK response as the result, on subsequent ones you'd expect NO entities created (different result) and a 400 BAD REQUEST (with an error message), hence it's still not idempotent. – Vala Jul 19 '12 at 13:59
  • Thor84no - OK, I understand the Create user scenario. So to update just the email address of an existing user? If I keep making the same request with the updated email nothing is going to change as the same updated email is sent, so its idempotent and therefore a PUT. – Paul Benbow Jul 19 '12 at 15:19