3 ms·

I would love to match curd with rest and I dnt find any ptoblems after that. Create - Put, Update - Post, Retrieve - Get, Delete - Delete

• yesbabyyes 15y ago
  It's common to use POST for creation and PUT for updates. PUT, as GET, should be idempotent.
  • div 15y ago
    DELETE is idempotent as well. GET and HEAD are not really "potent" as they don't cause state to change on the server (or at least shouldn't). So I usually prefer saying GET and HEAD are "safe". The difference between safe and idempotent is: - using an idempotent verb 0 or 1 times will have a different end state on the server. - using a safe verb 0 or 1 times will have the same end state on the server.
• ericmoritz 15y ago
  If you want to put HTTP methods in terms of SQL CRUD then think of it this way. POST is like a INSERT on a table with a auto incrementing primary key, you insert the data into the table and the SQL server tells you what the data is identified as. When you POST to a web service, the web service tells you what the data is identified as. For SQL: INSERT INTO people (first, last) VALUES ("Eric", "Moritz"); SELECT id FROM people WHERE first = "Eric" and last = "Moritz"; For HTTP: > POST /people/ > Content-Type: application/json > > {"first": "Eric", "last": "Moritz"} < HTTP/1.1 201 Created < Content-Location: /people/1 < < {"first": "Eric", "last": "Moritz"} PUT can function like an UPDATE on a table using it's primary key. For instance: For SQL: UPDATE people set first = "Eric" where id = 1; For HTTP: > PUT /people/1/first > Content-Type: text/plain > > Eric < HTTP/1.1 200 OK < Content-Type: application/json < < Eric A PUT can also be used to create a resource: For SQL: INSERT INTO people (id, first, last) VALUES (1, "Eric", "Moritz"); For HTTP: > PUT /people/1 > Content-Type: application/json > > {"first": "Eric", "last": "Moritz"} < HTTP/1.1 201 Created < < {"first": "Eric", "last": "Moritz"}
  • T-R 15y ago
    Great description - sorry, I accidentally downvoted when I meant to upvote.