A collection belongs to a bucket and stores records.
A collection is a mapping with the following attributes:
data
: (optional) attributes of the collection objectid
: the collection object idlast_modified
: the timestamp of the last modificationschema
: (optional) a JSON schema to validate the collection recordscache_expires
: (optional, in seconds) add client cache headers on read-only requests.More details...<collection-caching>
- and any field you might need
permissions
: theACLs <ACL>
for the collection object
Note
When the built-in plugin kinto.plugins.default_bucket
is enabled in configuration, a bucket default
is available.
Users are assigned to that bucket which can be used for their personal data.
When going through the default
bucket, the collections are created silently upon first access.
Applications can use this default bucket (e.g. /buckets/default/collections/contacts
will be the contacts of the current user.
Internally the user default bucket is assigned to an ID, and users can share data from their personnal bucket, by sharing its URL using the full ID <buckets-default-id>
.
Requires setting kinto.experimental_collection_schema_validation
to True
.
A JSON schema can optionally be associated to a collection.
Once a schema is set, records will be validated during creation or update.
If the validation fails, a error response will be returned.
Note
JSON schema is quite verbose and not an ideal solution for every use-case. However it is universal and supported by many programming languages and environments.
Just modify the schema
attribute of the collection object:
Example request
$ echo '{
"data": {
"schema": {
"title": "Blog post schema",
"type": "object",
"properties": {
"title": {"type": "string"},
"body": {"type": "string"}
},
"required": ["title"]
}
}
}' | http PATCH "http://localhost:8888/v1/buckets/blog/collections/articles" --auth token:admin-token --verbose
PATCH /v1/buckets/blog/collections/articles HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Authorization: Basic YWRtaW46
Connection: keep-alive
Content-Length: 236
Content-Type: application/json; charset=utf-8
Host: localhost:8888
User-Agent: HTTPie/0.8.0
{
"data": {
"schema": {
"properties": {
"body": {
"type": "string"
},
"title": {
"type": "string"
}
},
"required": [
"title"
],
"title": "Blog post schema",
"type": "object"
}
}
}
Example response
HTTP/1.1 200 OK
Access-Control-Expose-Headers: Backoff, Retry-After, Alert, Content-Length
Content-Length: 300
Content-Type: application/json; charset=UTF-8
Date: Fri, 21 Aug 2015 12:31:40 GMT
Etag: "1440160300818"
Last-Modified: Fri, 21 Aug 2015 12:31:40 GMT
Server: waitress
{
"data": {
"id": "articles",
"last_modified": 1440160300818,
"schema": {
"properties": {
"body": {
"type": "string"
},
"title": {
"type": "string"
}
},
"required": [
"title"
],
"title": "Blog post schema",
"type": "object"
}
},
"permissions": {
"write": [
"basicauth:780f1ecd9f57b01bef79608b45916d3bddd17f83461ac6240402e0ffff3596c5"
]
}
}
Once a schema has been defined, the posted records must match it:
$ echo '{"data": {
"body": "Fails if no title"
}}' | http POST http://localhost:8888/v1/buckets/blog/collections/articles/records --auth "token:admin-token"
HTTP/1.1 400 Bad Request
Access-Control-Expose-Headers: Backoff, Retry-After, Alert
Content-Length: 192
Content-Type: application/json; charset=UTF-8
Date: Wed, 10 Jun 2015 10:17:01 GMT
Server: waitress
{
"code": 400,
"details": [
{
"description": "'title' is a required property",
"location": "body",
"name": "title"
}
],
"errno": 107,
"error": "Invalid parameters",
"message": "'title' is a required property"
}
Kinto does not take care of schema migrations. But it gives the basics for clients to manage it.
If the validation succeeds, the record will receive a schema
field with the schema version (i.e. the collection current last_modified
timestamp).
It becomes possible to use this schema
field as a filter on the collection records endpoint in order to obtain the records that were not validated against a particular version of the schema.
For example, GET /buckets/blog/collections/articles/records?min_schema=123456
.
In order to remove the schema of a collection, just modify the schema
field to an empty mapping.
Example request
echo '{"data": {"schema": {}} }' | http PATCH "http://localhost:8888/v1/buckets/blog/collections/articles" --auth token:admin-token --verbose
PATCH /v1/buckets/blog/collections/articles HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Authorization: Basic YWRtaW46
Connection: keep-alive
Content-Length: 26
Content-Type: application/json; charset=utf-8
Host: localhost:8888
User-Agent: HTTPie/0.8.0
{
"data": {
"schema": {}
}
}
Example response
HTTP/1.1 200 OK
Access-Control-Expose-Headers: Backoff, Retry-After, Alert, Content-Length
Content-Length: 171
Content-Type: application/json; charset=UTF-8
Date: Fri, 21 Aug 2015 12:27:04 GMT
Etag: "1440159981842"
Last-Modified: Fri, 21 Aug 2015 12:26:21 GMT
Server: waitress
{
"data": {
"id": "articles",
"last_modified": 1440159981842,
"schema": {}
},
"permissions": {
"write": [
"basicauth:780f1ecd9f57b01bef79608b45916d3bddd17f83461ac6240402e0ffff3596c5"
]
}
}
With the cache_expires
attribute on a collection, it is possible to add client cache control response headers for read-only requests. The client (or cache server or proxy) will use them to cache the collection records for a certain amount of time, in seconds.
For example, set it to 3600
(1 hour):
echo '{"data": {"cache_expires": 3600} }' | http PATCH "http://localhost:8888/v1/buckets/blog/collections/articles" --auth token:admin-token
From now on, the cache control headers are set for the GET requests:
http "http://localhost:8888/v1/buckets/blog/collections/articles/records" --auth token:admin-token
HTTP/1.1 200 OK
Access-Control-Expose-Headers: Backoff, Retry-After, Alert, Content-Length, Next-Page, Total-Records, Last-Modified, ETag, Cache-Control, Expires, Pragma
Cache-Control: max-age=3600
Content-Length: 11
Content-Type: application/json; charset=UTF-8
Date: Mon, 14 Sep 2015 13:51:47 GMT
Etag: "1442238450779"
Expires: Mon, 14 Sep 2015 14:51:47 GMT
Last-Modified: Mon, 14 Sep 2015 13:47:30 GMT
Server: waitress
Total-Records: 0
{
"data": [{}]
}
If set to 0
, the collection records become explicitly uncacheable (no-cache
).
echo '{"data": {"cache_expires": 0} }' | http PATCH "http://localhost:8888/v1/buckets/blog/collections/articles" --auth token:admin-token
HTTP/1.1 200 OK
Access-Control-Expose-Headers: Backoff, Retry-After, Alert, Content-Length, Next-Page, Total-Records, Last-Modified, ETag, Cache-Control, Expires, Pragma
Cache-Control: max-age=0, must-revalidate, no-cache, no-store
Content-Length: 11
Content-Type: application/json; charset=UTF-8
Date: Mon, 14 Sep 2015 13:54:51 GMT
Etag: "1442238450779"
Expires: Mon, 14 Sep 2015 13:54:51 GMT
Last-Modified: Mon, 14 Sep 2015 13:47:30 GMT
Pragma: no-cache
Server: waitress
Total-Records: 0
{
"data": []
}
Note
This can also be forced from settings, see configuration section <configuration-client-caching>
.