CODEWITHSUNDEEP
htmlapihttprest
eugene
eugene

Reputation: 41735

RESTful address for image list

I've looked at many SO answers about REST, but the concept is still not clear.
At least, it seemed to me naming(the URL) properly is central to what REST is.

How do I make my address scheme below restful?
(I have list of images, but for each request I present different subset of them)

image_list/recent      (all image sorted in descending)
image_list/recent/front/  (to request newer images than a client has. client will provide the latest image id he has) 

image_list/popular (sorted in popularity)
image_list/following/ (list of images of users that a client follows)
image_list/user_like/  (list of images a client likes)

how about when you have many operations that you can perform on a resource?

image/upload/
image/delete/
image/like/
image/dislike/
image/hide/

EDIT

This is the solution after looking at answers. (But I still have doubts and did indicate so)

First set

images/?mode=recent
images/?mode=recent_front
images/?mode=popular
images/?mode=following&user_id=3
images/?mode=like&user_id=3

Isn't it a convention to use images/ for all images even though the all images set keeps changing?
Why can't I just use images/recent then?

Second set

images/ POST  (to create)
images/ DELETE 
 (to delete, ok but I have not seen anyone using `DELETE`. Does anyone use it?)
images/3/like POST (OK there's a `like` DB entity)
images/3/dislike POST (umm but there's no dislike DB entity)
images/3/hide .. (there's no hide entity, it's a merely a field on image)

Upvotes: 1

Views: 70

Answers (1)

Elliot B.
Elliot B.

Reputation: 17681

As I'm sure you know, REST is much more than a naming scheme for URLs.

What's important with your URI naming scheme is that the URI uniquely identifies a particular resource/entity. Quoting directly from the Wiki page:

An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., a URI in HTTP).

In your case, you want your URIs to structured so that they can uniquely identify an image or the collection of all images as a whole. There is more than one way to do this. Some people prefer query strings and others (including myself) prefer including identifiers as part of the URI folder structure. REST doesn't dictate one or the other.

Think about what you need to identify an image--it could be a filename, but if your application is database driven, it's more likely you'd be using an index ID number. You could setup your URI as such:

http://YOURDOMAIN.TLD/API/IMAGE/232423

Where 232423 uniquely identifies the image.

Now on to your second question:

how about when you have many operations that you can perform on a resource?

With REST APIs over HTTP, the action is typically specified by the HTTP method you utilize. GET for retrieving data, POST for updating/inserting data and DELETE for deleting data. It's not common practice to have the URI itself specify the action--as you've done above. Please note, that I'm talking about what's common practice--the principles of REST don't dictate what HTTP methods should be used or the URI naming structure.

Taking your example of likes on an image, you should treat the likes on the page as a resource--a unique entity. There are different actions that you want to do with this entity such as: 1. look up the number of likes on an image, 2. add a new like to the total.

For your REST method to like an image, you could set it up as a POST to a URI like this:

http://YOURDOMAIN.TLD/API/IMAGE/232423/LIKE

Where 232423 is an identifier for the image and LIKE refers to the likes on that particular image.

If you wanted to retrieve the number of likes on the image, use the same URI, but switch the HTTP method to GET.

Upvotes: 1

Related Questions