Photo content separated out from meta-data

[keananf]

This PR entails the simplest implementation of this requirement, and needs slightly altered still.

Included:

• Currently, all photo-related APIs have been changed so that they no longer return photo-contents. Instead, they simply return all 'meta-data' for the photo.
• File extensions are now stored. Only certain file extensions are permitted (jpg, png, gif). Others are rejected.
• A new endpoint has also been added. It returns the raw content of the file, and the URL includes file extension information such that the client can interpret the returned contents.

[keananf]

The main things I'm looking for feedback on are the explicit storage of the file extension, as well as the endpoint for retrieving photo contents.

If I remember correctly, @gthedev mentioned having the filename in the url? If this is the case, could this be a suitable endpoint:

• GET /albums/{albumId}/photos/{name.ext}

Would appreciate feedback on this.

[keananf]

@stuartkumar0630 @gthedev @zlan18 Delete your DB files when this PR lands

[gthedev]

@keananf Yes, if we store the contents in the database (rather than file system), then the endpoint would be suitable. I would suggest dropping the album part since it would be useful to retrieve photo contents without knowing its albumId, something like: GET /photos/{id}.{ext} - I've used id since that's unique whereas photo name can duplicate (presumably)

Or perhaps GET /photos/content/{id}.{ext} or something similar to avoid clashing with the meta data endpoint of GET /photos/{id}?

[keananf]

@gthedev That's perfect. Great idea. I'll change it quickly

[keananf]

@gthedev I ended up going with: GET /photos/content/{id.ext}

[keananf]

@gthedev you're right. I had to change it, so now we have explicit apis for fetching PNGs / JPGs.

• GET /photos/content/png/{id}.png
• GET /photos/content/jpg/{id}.jpg