Url pattern for making a 'like' with a REST API

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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