We are currently creating a web app that mimics how flickr works as a project.
In this app, we have a galleries and photos.
In each gallery, we store the photo ids in an array.
gallery.photos = [ photoId1, photoId2, photoId3 ]
If we want to delete a photo from the gallery, however the photo stays on the database and can be accessed if you go to the user's profile but not from the gallery.
so if we do DELETE url/gallery/photos/photoId3 then GET url/gallery/photos/photoId3, it would return an Error 404.
There's an argument currently happening on whether we should use DELETE or PUT.
some say DELETE as we are deleting things and photo isn't accessible from that url.
others say PUT as we are just editing the list of photo ids.
So, my question is, is there a common convention when it comes to this problem ?
is there a common convention when it comes to this problem ?
The important thing to recognize is that DELETE and PUT are of the transfer of documents over a network domain.
We use the standard methods in standard ways so that general purpose components can understand what the messages mean and do intelligent things.
If the semantics of the request are "the target uri should answer GET requests with a 404", then DELETE is appropriate. The underlying details of how your implementation achieves this are irrelevant.
Note that the definition of DELETE is pretty explicit about the limits of the semantics
If the target resource has one or more current representations, they might or might not be destroyed by the origin server, and the associated storage might or might not be reclaimed, depending entirely on the nature of the resource and its implementation by the origin server (which are beyond the scope of this specification).
Where things get really messy: HTTP gives us agreement on the meaning of the semantics of messages, but does not restrict implementations. In particular, it is perfectly valid that a DELETE of one resource would also change the representation of some other resource, or vice versa.
Imagine, if you will, that the gallery is a web page (/gallery/1/photos/webpage.html), with links to images, including a link to /gallery/1/photos/3.
DELETE /gallery/1/photos/3
That removes the association between the URI and the image data, but it doesn't (necessarily) change the web page, so you get a broken link.
PUT /gallery/1/photos/webpage.html
That takes the link out of the web page, but of course the image can still be accessed directly via its URI.
(Note: if your profile was using the same URI for the image as your gallery, then this is more likely to be the model you want to use. We take the link out of this web page, but not out of profile.html. DELETE would produce 404's for ALL web pages that link to the picture).
If you want both - when the DELETE happens, the web page should be updated automatically, or vice versa - you can do that within your implementation (side effects are allowed). BUT... general purpose components will not necessarily know that both things have happened. For example, a general purpose cache isn't going to know that the webpage changed when you DELETE the image. And it won't know that you removed the image when you edit the web page.
Which is to say, we don't have a standard way to include in the HTTP response metadata that describes the other resources that have been changed by a request.
You can, of course, include that information in the response so that a bespoke component can do intelligent things.
DELETE /gallery/1/photos/photoId3
200 OK
Content-Type: text/plain
Deleted: /gallery/1/photos/photoId3
Changed: /gallery/1/photos/webpage.html
GET /gallery/galleryId/photos/photoId3 would return an Error 404 as photo isn't in that gallery, however GET /photos/photoId3 would still return the photo assuming you have the correct permissions
The good news: general purpose components don't know that there is any relationship between /gallery/galleryId/photos/photoId3 and /photos/photoId3. Again, the fact that they share information under the covers is an implementation detail hidden behind the HTTP facade.