Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change media endpoint structure #247

Merged
merged 103 commits into from May 29, 2017

Conversation

Projects
None yet
4 participants
@eduardoboucas
Copy link
Member

eduardoboucas commented Apr 27, 2017

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

jimlambie added some commits Jan 12, 2017

feat: add readPreference configuration option
Default to “secondaryPreferred”

Close #156
feat: add readPreference configuration option
Default to “secondaryPreferred”

Close #156
Merge branch 'feature/upgrade-mongo-driver' of https://github.com/dad…
…i/api into feature/upgrade-mongo-driver

# Conflicts:
#	test/unit/model/index.js
@eduardoboucas

This comment has been minimized.

Copy link
Member Author

eduardoboucas commented May 22, 2017

@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? 😇

jimlambie added some commits May 22, 2017

Merge branch 'master' of https://github.com/dadi/api into feat/media-…
…endpoint

# Conflicts:
#	dadi/lib/auth/index.js
#	dadi/lib/index.js
#	test/acceptance/app.js
@eduardoboucas

This comment has been minimized.

Copy link
Member Author

eduardoboucas commented May 22, 2017

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 added some commits May 29, 2017

@jimlambie

This comment has been minimized.

Copy link
Member

jimlambie commented May 29, 2017

Close #156
Close #171

jimlambie added some commits May 29, 2017

Merge pull request #287 from dadi/fix/sort-key-with-index-error
fix: check index object keys for sort key

@jimlambie jimlambie merged commit 450540d into master May 29, 2017

1 of 3 checks passed

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/travis-ci/push The Travis CI build is in progress
Details
security/snyk No new vulnerabilities
Details

@jimlambie jimlambie removed the in progress label May 29, 2017

@mingard mingard referenced this pull request May 30, 2017

Closed

Media store documentation #41

@jimlambie jimlambie deleted the feat/media-endpoint branch Jun 3, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.