Releases: dadi/api
Version 2.1.0
This version adds some useful properties to documents added to a history collection:
action: possible values are "update", "delete" and the appropriate value is selected when updating/deleting recordsoriginalDocumentId: the identifier of the parent document
In addition, when a document is deleted, it's latest state is written into the history collection, if enabled.
Version 1.16.8
This version adds some useful properties to documents added to a history collection:
action: possible values are "update", "delete" and the appropriate value is selected when updating/deleting recordsoriginalDocumentId: the identifier of the parent document
In addition, when a document is deleted, it's latest state is written into the history collection, if enabled.
Installation notes
Installing from NPM using the command npm install @dadi/api will by default install the version with the "latest" tag. Currently, the "latest" version is 2.1.0. To install this version (1.16.8) use the command npm install @dadi/api@one, where "one" is the tag for the Version 1.x branch.
Version 2.0.0
Changed
Upgraded MongoDB driver
Upgrade MongoDB driver to 2.2.x, from the existing 1.4.x version.
Fixed create-client script
- use correct
accessTypeproperty in client store documents - abort if chosen clientId exists already
Generate new documents from a pre-composed document
It is now possible to send API a full document containing pre-composed Reference fields. API will translate such a request into individual documents for the relevant collections. This functionality reduces the number of API calls that must be made from an application when inserting data.
For example
Assume we have two collections, people and cars. cars is a Reference field within the people collection schema. Given the following body in a POST request to /1.0/car-club/people:
{
"name": "Joe",
"cars": [
{
"model": "Lamborghini Diablo",
"year": 1991
}
]
}API will automatically create new documents in the cars collection and use the new identifier value in the people document. The final people document would look similar to this:
{
"name": "Joe",
"cars": [
"587cb6aa80222c9e7266cec0"
]
}Media collections
This version introduces a few changes to how media is handled by API.
The concept of media collections has been abstracted from the public API. It removes the requirement for a collection schema, instead 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 will look into making the schema adapt to the type of file being uploaded.
Endpoints
| Method | Endpoint | Purpose | Example |
|---|---|---|---|
| POST | /media/sign |
Requesting a signed URL for a media upload | |
| POST | /media/:signedUrl |
Uploading a media asset | |
| GET | /media |
Listing media assets | |
| GET | /media/:assetPath |
Access a specific media asset | /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). It is also possible to add additional "media buckets", configured as an array in the media.buckets configuration parameter.
Endpoints
Here are the same media collection endpoints for interacting with a media bucket called mediaAvatars:
| Method | Endpoint | Purpose | Example |
|---|---|---|---|
| POST | /media/mediaAvatars/sign |
Requesting a signed URL for a media upload | |
| POST | /media/mediaAvatars/:signedUrl |
Uploading a media asset | |
| GET | /media/mediaAvatars |
Listing media assets | |
| GET | /media/mediaAvatars/:assetPath |
Access a specific media asset | /media/mediaAvatars/2017/04/27/flowers.jpg |
Naming conflicts
If 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.
Discovering media buckets
Added information about media buckets to the /api/collections endpoint, indicating a list of the available media buckets as well as the name of the default one.
GET /api/collections
{
"collections": [
{
"version": "1.0",
"database": "library",
"name": "Articles",
"slug": "articles",
"path": "/1.0/library/articles"
},
{
"version": "1.0",
"database": "library",
"name": "Books",
"slug": "books",
"path": "/1.0/library/books"
}
],
"media": {
"buckets": [
"authorImages",
"mediaStore"
],
"defaultBucket": "mediaStore"
}
}Add url property to media documents
Instead of replacing the contents of path, leave that as it is and write the full URL to a new property called url.
"image": {
"_id": "591b5f29795b683664af01e9",
"fileName": "3RdYMTLoL1X16djGF52cFtJovDT.jpg",
"mimetype": "image/jpeg",
"width": 600,
"height": 900,
"contentLength": 54907,
"path": "/media/2017/05/16/3RdYMTLoL1X16djGF52cFtJovDT-1494966057926.jpg",
"createdAt": 1494966057685,
"createdBy": null,
"v": 1,
"url": "http://localhost:5000/media/2017/05/16/3RdYMTLoL1X16djGF52cFtJovDT-1494966057926.jpg"
}Hook configuration endpoints
Extended the hooks config endpoint (/api/hooks/:hookName/config) to accept POST, PUT and DELETE requests to create, update and delete hooks, respectively.
Other
- #245: fix media path formatting
- #246: ignore _id field in query when processing query filters
- #257: improve performance of Reference field composition
- #265: validate arrays against schemas in POST requests
- #284: check indexes correctly when given a sort key
- remove
apiVersionquery property when composing reference fields, improves performance
Added
MongoDB readPreference configuration
Added readPreference configuration option. Default is secondaryPreferred. Closed #156
"database": {
"hosts": [
{
"host": "127.0.0.1",
"port": 27017
}
],
"username": "",
"password": "",
"database": "api",
"ssl": false,
"replicaSet": "",
"enableCollectionDatabases": false,
"readPreference": "primary"
}API baseUrl
We've introduced a server.baseUrl configuration parameter, which will be used to determine the URL of media assets when using the disk storage option.
"baseUrl": {
"protocol": "http",
"port": 80,
"host": "mydomain.com"
}Post install script
Added a post install script which runs following an install of API from NPM. A development configuration file is created along with a basic workspace directory containing two collections, an endpoint and a hook. No files are overwritten if the config and workspace directories already exist.
Version 1.16.6
Changed
- improved check within composer module that ignores "undefined" values as well as "null"
Version 1.16.5
v1.16.5 Version 1.16.5
Version 1.16.3
v1.16.3 chore: version 1.16.3
Version 1.16.1
- Upload media
- Resolves references when sending PUT requests
Version 1.15.5
Changed
- #226: historyFilters are applied to the primary query, causing only
_idandhistoryfields to be returned. This change removes the historyFilters before the primary query and reapplies them when fetching history data.
v1.15.4
<a name"1.15.4">
1.15.4 (2017-02-15)
Bug Fixes
- pass auth indicator to connection (1d3ebed4)
How to create an API client
From the root of your API installation, run the following command:
npm explore @dadi/api -- npm run create-clientThis will start the Client Record Generator, accessing you a series of questions and finally inserting the client record into the database you have configured.
To ensure the correct database is used for your environment, add an environment variable to the command:
NODE_ENV=production npm explore @dadi/api -- npm run create-client