标签云

微信群

扫码加入我们

WeChat QR Code

Possible Duplicate:PUT vs POST in RESTI 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/[email protected]


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.

2019年12月07日07分32秒

On first reading about REST I decided Create - POST, update - PUT, delete - DELETE but it doesn't seem to be that simple. jcalcote.wordpress.com/2008/10/16/…

2019年12月07日07分32秒

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.

2019年12月07日07分32秒

Thor84no yes it doesn't matter but when emails are going in URI, even with HTTPS it's possible to sniff them

2019年12月07日07分32秒

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.

2019年12月07日07分32秒

"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?

2019年12月07日07分32秒

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.

2019年12月08日07分32秒

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.

2019年12月07日07分32秒