This page describes some design decisions behind user photo.

Requirements:

Questions/answers:

There are multiple possible flavors for the REST API between which we have to choose. These are explained below.

Option 1 - Attached to user

The path for the photo link is a subresource of the user.

PathMethodDescriptionPassword required?
/users/{userID}/photoPUTUpload a new photo(tick)
/users/{userID}/photoDELETERemove the current photo(tick)
/users/{userID}/photoGETDownload your own photo(tick)
/users/{userID}/buddies/{buddyID}/photoGETDownload the photo of a buddy(tick)


Pro/con:

Option 2 - Detached

PathMethodDescriptionPassword required?
/userPhotos/POST

Upload a new photo

(warning) Can be accessed unauthorized, so DOS prevention should be enabled

(error)
/userPhotos/{userPhotoId}GET

Download a photo by ID

(error)
/userPhotos/{userPhotoId}DELETE

Remove a photo by ID

(question) How to authorize for this action? Send the password header and retrieve the attached user ID from the UserPhoto entity?

(question)
/users/POST

Allow to link a photo on user account creation by URL in the _links section

(tick)
/users/{userID}PUTAllow to link/unlink a photo on user update by URL in the _links section(tick)

Pro/con:

Option 3 - Attached to user, separately retrievable 

PathMethodDescriptionPassword required?
/users/{userID}/photoPUTUpload a new photo(tick)
/users/{userID}/photoDELETERemove the current photo(tick)
/userPhotos/{userPhotoId}GETDownload a photo.(error)
/users/{userID}GETFetch the photo link when fetching the user (whether buddy or own user)(tick)

Pro/con: