I have an API route as so:

GET /api/item/like

Which makes a like object between the logged in user and item object, and it works fine.

Is this the correct way to have a user 'like' an object? Or should I use PUT or POST? If so, how?


Since you are creating a new resource which you already have a URI for on the client end you should use PUT to create this resource.

Your URL scheme should probably change though. /api/item/like has no connection to the user that linked the item. So how do you know which user liked it? A resource should have a unique URI. If you actually have lots and lots of 'like' resources, one for each user that liked the item, then you should have a unique URI for each one.

Change this to something like

PUT /api/item/likes/{userID}

and then the act of the client putting this to the server signifies that {userID} liked this item.

| improve this answer | |
  • 1
    You're going to need at least an ItemID and a UserID. – Robert Harvey Jun 5 '19 at 17:26
  • Thank you, you are correct. I will make routes like: PUT /api/item/likes/[userid] DEL /api/item/likes/[userid] – TaimoorAhmad Jun 5 '19 at 20:37
  • I decided to instead make it /recipes/id/like and /recipes/id/unlike both using PUT. With Django I can get the current user through request. Thank you! – TaimoorAhmad Jun 5 '19 at 21:13
  • Just bear in mind doing it like that means you don't have a unique URL for the resource, which may cause trouble at a later date (for example how can one user check if another user has liked an item). If your design is relatively simple this may not be an issue, but it highlights the problem when a resource does not have a unique URI – Cormac Mulhall Jun 6 '19 at 10:19
  • Thanks Cormac. Indeed, I don't have a social aspect to my Django project, therefore there's no need for a user to be able to see other users' likes. Though I understand this limits me in the future if I wanted to add a social aspect to the project. – TaimoorAhmad Jun 6 '19 at 10:39

No, this is decidedly against the intention of the GET operation.

See this, in particular:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

In other words, GET operations are merely queries against the backing data that do not modify that backing data in any way.

POST is probably what you should be using:

POST is designed to allow a uniform method to cover the following functions:

  • Annotation of existing resources;
  • Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
  • Providing a block of data, such as the result of submitting a form, to a data-handling process;
  • Extending a database through an append operation.

Bolding in both quotes my own for emphasis.

| improve this answer | |

Dose it fetch the object with no change in state of the server? If not it is CRUD (not REST), and should use PUT.

Representational State Transfer (REST) is a software architectural style that defines a set of constraints to be used for creating Web services. Web services that conform to the REST architectural style, called RESTful Web services (RWS), provide interoperability between computer systems on the Internet. RESTful Web services allow the requesting systems to access and manipulate textual representations of Web resources by using a uniform and predefined set of stateless operations. Other kinds of Web services, such as SOAP Web services, expose their own arbitrary sets of operations. — https://en.wikipedia.org/wiki/Representational_state_transfer

In computer programming, create, read, update, and delete (CRUD) are the four basic functions of persistent storage. Alternate words are sometimes used when defining the four basic functions of CRUD, such as retrieve instead of read, modify instead of update, or destroy instead of delete. CRUD is also sometimes used to describe user interface conventions that facilitate viewing, searching, and changing information; often using computer-based forms and reports. The term was likely first popularized by James Martin in his 1983 book Managing the Data-base Environment. The acronym may be extended to CRUDL to cover listing of large data sets which bring additional complexity such as pagination when the data sets are too large to be easily held in memory. — https://en.wikipedia.org/wiki/Create,_read,_update_and_delete

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.