How to create compound documents? - json-api

I'm thinking of using the JSONAPI standard for the design of our API. One thing this API must be able to do, is accept a compound document (several layers deep) and create it. The root object owns all descendants ('to-many' relationships) which the server knows nothing about at that point, so it's not possible for the client to provide an id.
Is this supported by the specification or does the client have to issue http requests for every object in the document in order?

from http://jsonapi.org/format/#document-compound-documents
Compound documents require "full linkage", meaning that every included
resource MUST be identified by at least one resource identifier object
in the same document. These resource identifier objects could either
be primary data or represent resource linkage contained within primary
or included resources. The only exception to the full linkage
requirement is when relationship fields that would otherwise contain
linkage data are excluded via sparse fieldsets.
{
"data": [{
"type": "articles",
"id": "1",
"attributes": {
"title": "JSON API paints my bikeshed!"
},
"links": {
"self": "http://example.com/articles/1"
},
"relationships": {
"author": {
"links": {
"self": "http://example.com/articles/1/relationships/author",
"related": "http://example.com/articles/1/author"
},
"data": { "type": "people", "id": "9" }
},
"comments": {
"links": {
"self": "http://example.com/articles/1/relationships/comments",
"related": "http://example.com/articles/1/comments"
},
"data": [
{ "type": "comments", "id": "5" },
{ "type": "comments", "id": "12" }
]
}
}
}],
"included": [{
"type": "people",
"id": "9",
"attributes": {
"first-name": "Dan",
"last-name": "Gebhardt",
"twitter": "dgeb"
},
"links": {
"self": "http://example.com/people/9"
}
}, {
"type": "comments",
"id": "5",
"attributes": {
"body": "First!"
},
"links": {
"self": "http://example.com/comments/5"
}
}, {
"type": "comments",
"id": "12",
"attributes": {
"body": "I like XML better"
},
"links": {
"self": "http://example.com/comments/12"
}
}]
}

Related

Logic App > Cosmos PartitionKey Not Matching Error

I'm scared to put this out there because it should be so easy and I am facing the same issue as the post here, here and here and I have tried each of the answers to no avail. Below is the current Resulting Input (redacted) and Related CodeView of the inputs.
The Result
{
"method": "post",
"headers": {
"x-ms-documentdb-raw-partitionkey": "\"2020\""
},
"path": "/dbs/xxxx/colls/smtp/docs",
"host": {
"connection": {
"name": "/subscriptions/..."
}
},
"body": {
"category": [
[
"cat facts"
]
],
"email": "example#test.com",
"event": "processed",
"id": "yada",
"partitionKey": "\"2020\"",
"sg_event_id": "yada yada",
"sg_message_id": "yada",
"smtp-id": "yada",
"timestamp": 1604345542
}
}
The Code View
{
"inputs": {
"body": {
"category": [
"#items('For_each')['category']"
],
"email": "#items('For_each')['email']",
"event": "#items('For_each')['event']",
"id": "#items('For_each')['sg_message_id']",
"partitionKey": "\"#{formatDateTime(utcNow(),'yyyy')}\"",
"sg_event_id": "#items('For_each')['sg_event_id']",
"sg_message_id": "#items('For_each')['sg_message_id']",
"smtp-id": "#items('For_each')['smtp-id']",
"timestamp": "#items('For_each')['timestamp']"
},
"headers": {
"x-ms-documentdb-raw-partitionkey": "\"#{formatDateTime(utcNow(),'yyyy')}\""
}
}
The error I'm getting is the usual one - PartitionKey extracted from document doesn't match the one specified in the header
I just can't see what I'm missing here now.
Thanks all.
First, as Matias comments, check your partition key path.
Then, change this code "partitionKey": "\"#{formatDateTime(utcNow(),'yyyy')}\"", to "partitionKey": "#{formatDateTime(utcNow(),'yyyy')}", in your document.
It works fine on my side:

Graph API search by metadata / column value

I'm developping an application using MS Graph API on a sharepoint site.
I'm trying to build the URL that allow me to find a drive item in a library with a colum param.
Actually I built this get URL to retrieve the drive items in the library:
https://graph.microsoft.com/v1.0/sites/{mainSite}:/sites/{subsite}:/lists/{libname}/items
I obtain a JSON with all files.
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(microsoft.graph.list)('myLib')/items",
"value": [
...
{
"#odata.etag": "\"7773c0de-bed1-425b-9065-2310c600757b,6\"",
"createdDateTime": "2019-11-21T09:19:57Z",
"eTag": "\"7773c0de-bed1-425b-9065-2310c600757b,6\"",
"id": "24",
"lastModifiedDateTime": "2020-05-27T09:09:05Z",
"webUrl": "https://xxxx.sharepoint.com/sites/SUBSITE/myLib/Cartouche.docx",
"createdBy": {
"user": {
"email": "xxx#xxx.fr",
"id": "5fe24d57-1357-4fef-9cae-bfd79b0bf831",
"displayName": "David Vera"
}
},
"lastModifiedBy": {
"user": {
"email": "dvera#dsidiff.fr",
"id": "5fe24d57-1357-4fef-9cae-bfd79b0bf831",
"displayName": "David Vera"
}
},
"parentReference": {
"id": "1836034d-8a35-4488-995e-a7fe9cd30b4c",
"siteId": "xxx.sharepoint.com,82a2327c-e2cf-4d30-b529-31c3bcdcda5e,fbi3zrs9-b07a-4777-945b-3b42c5c876d"
},
"contentType": {
"id": "0x010100E4AD49D3A8873645A2803D49D2A4BF60"
}
},
...
]
}
I tried to use filter :
https://graph.microsoft.com/v1.0/sites/{mainSite}:/sites/{subsite}:/lists/{libname}/items?expand=fields(select=CODE_ANNONCEUR,val)&filter=fields/val eq 'myself'
It returns me :
{
"error": {
"code": "-1, Microsoft.SharePoint.Client.InvalidClientQueryException",
"message": "The expression « fields (select ») is not valid.",
"innerError": {
"request-id": "c3edc510-2d63-4f21-86cd-a377fb02d324",
"date": "2020-05-27T09:44:23"
}
}
}
I solved the issue this way :
https://graph.microsoft.com/v1.0/sites/xxx.sharepoint.com:/sites/yyy:/lists/zzz/items?expand=fields/CODE_ANNONCEUR&filter=fields/CODE_ANNONCEUR eq 'stringExpected'

Watson Assistant (Conversation) service behaves differently when created via API versus created in the Browser

We are seeing different behaviour when we create a workspace in the WebInterface versus when we create the same conversation via the API.
The JSON export for the dialognode is the same:
{ "type": "standard",
"title": "SmallTalk: weerbericht",
"output": {
"text": {
"values": [],
"selection_policy": "sequential" } },
"parent": "smalltalk_container",
"context": { "user_weer": "#weerbericht",
"user_location": "#plaatsnamen" },
"metadata": {
"_customization": {
"mcr": false } },
"next_step": { "behavior": "jump_to", "selector": "condition", "dialog_node": "node_33_1519129633532"
},
"conditions": "#ST_weersbericht",
"description": null,
"dialog_node": "node_9_1517408489377",
"previous_sibling": "node_3_1518680265483" },
But the behaviour is different, which can be explained when we look at the UI
there is a difference
This is the UI for the dialogNode created via the browser
This is the UI for the same dialogNode created via the API
One difference we found is the Multiple Reponse switch:
It should be OFF (image on the right) and as per the JSON (mcr:false).
But even when we switch it on manually, the context variables don't show.
What should I be looking for in the API to fix this ?
The dialog model for multiple condition responses is that the parent node needs to be either standard dialog node or frame. Now when adding a multiple condition response to this node (and hence making an MCR node out of that parent node) you need to add a dialog node with "type":"response_condition" under this node.
This is a way how to create multiple condition responses through the api.
To give you and example to create MCR node:
The JSON of dialog nodes that need to pushed through the API will look like:
{
"type": "standard",
"title": "mcr node",
"output": {
},
"parent": null,
"context": null,
"metadata": {
"_customization": {
"mcr": true
}
},
"next_step": null,
"conditions": "#book_flight",
"digress_in": "does_not_return",
"description": null,
"dialog_node": "node_8_1525086089064",
"digress_out": "allow_all",
"previous_sibling": null
},
{
"type": "response_condition",
"title": null,
"output": {
"text": {
"values": ["I see city entity!"]
}
},
"parent": "node_8_1525086089064",
"context": null,
"metadata": {
},
"next_step": null,
"conditions": "#city",
"description": null,
"dialog_node": "node_9_1525086100114",
"previous_sibling": null
},
{
"type": "response_condition",
"title": null,
"output": {
"text": {
"values": ["I don't see anything."]
}
},
"parent": "node_8_1525086089064",
"context": null,
"metadata": {
},
"next_step": null,
"conditions": "anything_else",
"description": null,
"dialog_node": "node_10_1525086122332",
"previous_sibling": "node_9_1525086100114"
}

Empty sparse fieldset in JSON API

I have a resource (e.g. posts) which has a to-many relationship to other resources (e.g. comments). I do not need any fields of the related resource but their self-links (to fetch them asynchronously on demand). The response should look something like this:
{
"links": {
"self": "http://example.com/posts/1?xxx",
},
"data": [{
"type": "posts",
"id": "1",
"attributes": {
"title": "JSON API paints my bikeshed!"
},
"relationships": {
"comments": {
"links": {
"self": "http://example.com/posts/1/relationships/comments",
"related": "http://example.com/posts/1/comments"
},
"data": [
{ "type": "comments", "id": "5" },
{ "type": "comments", "id": "12" }
]
}
},
"links": {
"self": "http://example.com/posts/1"
}
}],
"included": [{
"type": "comments",
"id": "5",
"links": {
"self": "http://example.com/comments/5"
}
}, {
"type": "comments",
"id": "12",
"links": {
"self": "http://example.com/comments/12"
}
}]
}
My question is how should the URL for the request look like?
My idea would be to include the comments and then use an empty sparse fieldset to avoid getting any comment fields but just the self link (+id, type).
Hence, it should look something like http://example.com/posts/1?include=comments&fields[comments]=[].
So I need something like an empty sparse fieldset.
The JSON API specification does not say much about sparse fieldsets (http://jsonapi.org/format/#fetching-sparse-fieldsets) and their relation to links.
The JSON API was able to answer my question.
In short, the correct way to specify an empty sparse fieldset would be:
http://example.com/posts/1?include=comments&fields[comments]=
There's a discussion going on about whether to include the links to individual relationship items in the relationship object:
{
"links": {
"self": "http://example.com/posts/1",
},
"data": [{
"type": "posts",
"id": "1",
"attributes": {
"title": "JSON API paints my bikeshed!"
},
"relationships": {
"comments": {
"links": {
"self": "http://example.com/posts/1/relationships/comments",
"related": "http://example.com/posts/1/comments",
"item": [ "http://example.com/comments/5", "http://example.com/comments/12" ]
},
"data": [{
"type": "comments",
"id": "5",
"links": {
"about": "http://example.com/comments/5"
}
}, {
"type": "comments",
"id": "12",
"links": {
"about": "http://example.com/comments/12"
}
}]
}
},
"links": {
"self": "http://example.com/posts/1"
}
}]
}

No self href in embedded HAL resource collection

I use the self href from my HAL resources on the client side to find the right path for the CRUD operations. In single(ton) resources this is working fine (see the address resource below, the _links containing the self href is included in the embedded resource) but when it comes down to collections this is a different story. The _links of a collection are not rendered when the collection is in _embedded.
Earlier I worked around this problem by reading the url form the first child. But this is not sufficient. In case the collection is empty I only have
an empty array with no possibility to extract the url like that. If I want to create a new item in the collection I would like that my client knows where to send data using POST by reading the self href from _links. Is it a good idea to include the _links to my collection like this:
{
"_links": {
"self": {
"href": "http://example.com/api/v1/users/1"
}
},
"_embedded": {
"contacts": {
Now I have access to the self href here:
"_links": {
"self": {
"href": "http://example.com/api/v1/users/1/contacts"
}
},
"_embedded": {
"contacts": [
{
"_links": {
"self": {
"href": "http://example.com/api/v1/users/1/contacts/2"
}
},
"id": "2",
"name": "John Smith"
},
{
"_links": {
"self": {
"href": "http://example.org/api/v1/users/1/contacts/3"
}
},
"id": "3",
"name": "Jane Doe"
}
],
}
},
"address": {
"_links": {
"self": {
"href": "http://example.com/api/v1/addresses/1"
}
},
"street": "Bakerstreet 11",
"postal code": "123456",
"city": "Some city",
"country": "Some country",
}
},
"id": "1",
"name": "John Doe"
}
EDIT (one year later)
In the end I solved this by always adding the links of embedded resources to the parent resource. So in the example above my response object would look like this:
{
"_links": {
"self": {
"href": "http://example.com/api/v1/users/1"
},
"contacts": {
"href": "http://example.com/api/v1/users/1/contacts"
},
"address": {
"href": "http://example.com/api/v1/addresses/1"
}
},
"_embedded": {
"contacts": [
{
"_links": {
"self": {
"href": "http://example.com/api/v1/users/1/contacts/2"
}
},
"id": "2",
"name": "John Smith"
},
{
"_links": {
"self": {
"href": "http://example.org/api/v1/users/1/contacts/3"
}
},
"id": "3",
"name": "Jane Doe"
},
],
"address": {
"_links": {
"self": {
"href": "http://example.org/api/v1/addresses/1"
}
},
"street": "Bakerstreet 11",
"postal code": "123456",
"city": "Some city",
"country": "Some country",
}
},
"id": "1",
"name": "John Doe"
}
So no matter whether I embedded the resources or not I always know where they are located. And for the contacts collection I will have the link to my collection endpoint in the _links array and the contacts themselves in _embedded.
Yes. It's not only good practice to do so; it's recommended by the HAL spec:
Each Resource Object SHOULD contain a 'self' link that corresponds with the IANA registered 'self' relation (as defined by RFC5988) whose target is the resource's URI.
A collection of resources is itself a resource, don't forget.

Resources