Change media endpoint structure

[eduardoboucas]

As per the conversation on Slack this morning, this PR introduces a few changes to how media is handled by API.

Currently, media assets are stored in media collections, which consist of normal collections with a version, database and collection schema, accessible on the normal REST endpoints (i.e. /version/database/collectionName). All that differentiates them from normal data collections is a type property in the settings block set to media.

With this PR, the concept of media collections is abstracted from the public API. It removes the requirement for a collection schema, using a schema kept internally in API. At the moment it's hardcoded to store images (containing dimensions, size, mime type, etc.), but in the future we can look into making the schema adapt to the type of file being uploaded.

Endpoints

• Requesting a signed URL for a media upload:

  POST /media/sign
  

• Uploading a media asset

  POST /media/sign/:signedUrl
  

• Listing media assets

  GET /media
  

• Accessing a specific media asset

  GET /media/:assetPath (e.g. `/media/2017/04/27/flowers.jpg`)
  

Media buckets

Even though that's abstracted from the end user, assets still need to be stored in collections. Assets POSTed to /media will be stored in a mediaStore collection (configurable via the media.defaultBucket configuration parameter). We can have as many namespaces (what we called "media buckets") as we want. That's configurable as an array in the media.buckets parameter (defaulting to []).

This is how the endpoints look like for interacting with a media bucket called mediaAvatars:

• Requesting a signed URL for a media upload:

  POST /media/mediaAvatars/sign
  

• Uploading a media asset

  POST /media/mediaAvatars/sign/:signedUrl
  

• Listing media assets

  GET /media/mediaAvatars
  

• Accessing a specific media asset

  GET /media/mediaAvatars/:assetPath (e.g. `/media/mediaAvatars/2017/04/27/flowers.jpg`)
  

Naming conflicts

Whenever there is a data collection with the same name as one of the media buckets, API throws an error detailing the name of the conflicting collection.

API base URL

This also fixes the issue described in #245 by introducing a server.baseUrl configuration parameter, which will be used to determine the URL of the media assets when using the disk storage option.

---

@mingard can you confirm whether this meets the requirements?

@jimlambie could you share your thoughts on the approach/implementation? Happy to make any required changes.

Thanks!

Fix #260
Fix #245
Fix #265

[eduardoboucas]

@jimlambie We have some merge conflicts here. Could this be because you progressed the previous media implementation further? Could you help me sort this out so I don't break the internet? 😇

[eduardoboucas]

I propose that we add information about the media buckets to the /api/collections endpoint, indicating a list of the available media buckets as well as the name of the default one. Something like this:

GET /api/endpoints

{
  "collections": [
    {
      "version": "1.0",
      "database": "publish",
      "name": "Articles",
      "slug": "articles",
      "path": "/1.0/publish/articles"
    },
    {
      "version": "1.0",
      "database": "publish",
      "name": "Books",
      "slug": "books",
      "path": "/1.0/publish/books"
    },
    {
      "version": "1.0",
      "database": "publish",
      "name": "Publish authors",
      "slug": "users",
      "path": "/1.0/publish/users"
    }
  ],
  "media": {
    "buckets": [
      "userAvatars",
      "mediaStore"
    ],
    "defaultBucket": "mediaStore"
  }
}

[jimlambie]

Close #156
Close #171