We currently have a proof request like this:
{
"name": "pr",
"version": "1.0",
"nonce": "0994650939",
"requested_attributes": {
"attr0_referent": {
"name": "first_name",
"restrictions": [{
"cred_def_id": "credDefIdShareGlobal"
}]
}
},
"requested_predicates": {},
"non_revoked": {}
}
As you can see, on the restricton fields now we have only one restriction. Is it possible to have multiple restrictions on the same attribute (like the example beneath)?
{
"name": "pr",
"version": "1.0",
"nonce": "0994650939",
"requested_attributes": {
"attr0_referent": {
"name": "first_name",
"restrictions": [{
"cred_def_id": "credDefIdShareGlobal1"
}, {
"cred_def_id": "credDefIdShareGlobal2" // <-- Is this possible?
}]
}
},
"requested_predicates": {},
"non_revoked": {}
}
Well, to give some closure to this question, yeah. It works exactly like that.
To give more context, the attribute can be present in different schemas or different credentials and by adding the restrictions as shown they'll be dealt with as an "OR" so, the first one matching will be returned.
If you want to see an test example, I'll advise looking here: https://github.com/eduelias/indy-sdk/blob/MultipleReq/samples/nodejs/src/gettingStarted.js#L470
Related
Is there a mechanism in Swashbuckle that can prevent definitions from being created with referencing to them in parameters/responses/etc.?
By default, you might get a path that looks like this:
"/profile": {
"get": {
"summary": "Get my profile details.",
"produces": [
"application/json",
],
"parameters": [],
"responses": {
"200": {
"description": "Success",
"schema": {
"$ref": "#/definitions/ProfileModel"
}
}
}
}
}
But what I'd like is for it to expand the schema inline like this:
"/profile": {
"get": {
"summary": "Get my profile details.",
"produces": [
"application/json",
],
"parameters": [],
"responses": {
"200": {
"description": "Success",
"schema": {
"type": "object",
"properties": {
"id": {
"type": "string",
"description": "id"
},
"firstName": {
"type": "string",
"description": "firstName"
},
"surname": {
"type": "string",
"description": "surname"
},
"emailAddress": {
"type": "string",
"description": "emailAddress"
}
}
}
}
}
}
}
I reviewed this StackOverflow question and I don't think it's what I'm looking for (or maybe misinterpreted).
Taken a look through the Swashbuckle README to understand its capabilities but coming up short. Any help here would be most appreciated.
For additional context, looking at the Swashbuckle PDF documentation in section 1.7, I essentially want to bypass or revert the action they describe as
automatically generating a corresponding schema for user-defined reference types and reference the definition via the $ref keyword.
Digging into the codebase a little, it looks like it's not possible at the moment.
However, you can create a custom ISchemaGenerator from the one in source and alter the GenerateConcreteSchema method under the DataType.Object case to not return as reference and this solves the issue.
Given the following:
GET http://www.example.com/post/1?include=author
{
"type": "post",
"id": "1",
"attributes": {
"title": "It's a title.",
"description": "It's a description."
},
"relationships": {
"author": {
"links": {
"self": "http://example.com/articles/1/relationships/author",
"related": "http://example.com/people?filter[article]=1"
},
"data":{
"type":"people", "id":"9"
}
}
},
"included":[
{
"type":"people",
"id": "9",
"attributes": {
"first-name": "Dan",
"last-name": "Gebhardt",
"twitter": "dgeb"
},
"links": {
"self": "http://example.com/people/9"
}
}
],
"links": {
"self": "http://example.com/articles/1"
}
}
If I were to append fields[post]=title, (i.e. GET http://www.example.com/post/1?include=author&fields[post]=title) should this prevent included (compound document) from displaying?
GET http://www.example.com/post/1?include=author&fields[post]=title
{
"type": "post",
"id": "1",
"attributes": {
"title": "It's a title.",
},
"relationships": {
"author": {
"links": {
"self": "http://example.com/articles/1/relationships/author",
"related": "http://example.com/people?filter[article]=1"
},
"data":{
"type":"people", "id":"9"
}
}
}
}
Or are compound documents still supposed to render?
Sparse Fieldsets and Compound Documents could be used together. The spec explicitly lists sparse fieldsets as the only allowed case in which a included resource may not be linked by another other resource in the same 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.
To directly answer your question: The spare fieldset should only affect the linkage between the resources (e.g. by not including the relationship field between them) but should not cause a resource to be not included that otherwise would.
I can successfully use the Newtonsoft.Json.Schema.Generation.JSchemaGenerator to generate valid JSONSchema for a given class. This works fine, however, a third party consumer requires that it has a
"allOf": [ { "$ref": "#/definitions/ClassName" } ]
block of code in the emitted JSON Schema.
I can currently get the output to appear as
{
"$id": "https://xxxxx/classname",
"definitions": {
"ClassName": {
"type": "object",
"properties": {
but I need it to look like
{
"$id": "https://xxxxx/classname",
"allOf": [
{
"$ref": "#/definitions/ClassName"
}
],
"definitions": {
"ClassName": {
"type": "object",
"properties": {
Does anybody know what I need to do to achieve this? There is only one class being referenced.
Currently, I have the generator using code like this:
var _jsonSchemaGenerator = new JSchemaGenerator();
_jsonSchemaGenerator.SchemaIdGenerationHandling = SchemaIdGenerationHandling.None;
_jsonSchemaGenerator.SchemaLocationHandling = SchemaLocationHandling.Definitions;
var schema = _jsonSchemaGenerator.Generate(typeof(T));
console.WriteLine(schema);
Any help would be appreciated.
Is it a violation of the JSON-API spec to allow reverse relationships to be created automatically?
I need to create resources that, when I link A to B in a relationship, automatically links B to A. In this way I can traverse A to find all of its Bs and can find the parent A from a B. However, I don't want to POST/PATCH to 2 relationships to get this right. I want to establish the relationship once.
Now I know that it is an implementation detail as to how the server maintains link/references as well as how the behaviour is established but I want to build the API in such a way that it doesn't violate the spec.
Assuming I have resources Books and Authors. Books have Authors and Authors have Books. The question is, once I relate an Author to a Book, I need the reverse relationship to be created as well. Is it a violation of the spec in any way to assume that this reverse relationship can be automatically created by simply doing one POST to the Books resource's relationship?
By way of example, starting with the book.
{
"data": {
"type": "books", "id": 123, "attributes": ...,
"links": { "self": "/books/123" },
"relationships": {
"self": "/books/123/relationships/authors",
"related": "/books/123/authors"
}
}
}
And the author
{
"data": {
"type": "authors", "id": 456, "attributes": ...,
"links": { "self": "/authors/456" },
"relationships": {
"self": "/authors/456/relationships/books",
"related": "/authors/456/books"
}
}
}
If I establish the link from a book to an author with a POST to /books/123/relationships/authors
{
"data": [{ "data": "authors", "id": "456" }]
}
Do I need to explicitly do the same for the Author 456 as a POST to /authors/456/relationships/books?
{
"data": [{ "data": "books", "id": "123" }]
}
Or can I let the server build the relationship for me so that I can avoid the second POST and just see the automatic reverse relationship at GET /authors/456/relationships/books?
From the perspective of the spec this is only one relationship represented from two different sides. author and book have a many-to-many relationship. This relationship could be represented in author's resource object as well as book's resource object and of course also via there relationship links. Actually it would be a violation of the spirit of the specification if representations wouldn't match. Having one-sided relationships is another story but in that case one side wouldn't know about the relationships at all (e.g. a book is associated with an author but the author model does not know which books are associated with it).
A post to either one side of that relationship creates the relationship between the two records. It shouldn't matter which side is used to create that relationship and if it's created as part of a creation / update to a resource via it's resource object or via a relationship link representing that relationship. The same applies to deletion of that relationship.
Maybe an example would make that even more clear. Let's assume a book is created with a POST to /books?include=author having these payload:
{
"data": {
"type": "books",
"relationships": {
"author": {
"data": {
"type": "authors",
"id": "1"
}
}
}
}
}
The response may look like this:
{
"data": {
"type": "books",
"id": "7",
"relationships": {
"author": {
"data": { "type": "authors", "id": "1" }
}
}
},
"included": [
{
"type": "authors",
"id": "1",
"relationships": {
"books": {
"data": [
{ "type": "books", "id": "7" }
]
}
}
}
]
}
Why is the self and related references different in the below JSONAPI resource? Aren't they pointing to the same resource? What is the difference between going to /articles/1/relationships/tags and /articles/1/tags?
{
"links": {
"self": "/articles/1/relationships/tags",
"related": "/articles/1/tags"
},
"data": [
{ "type": "tags", "id": "2" },
{ "type": "tags", "id": "3" }
]
}
You can read about that here: https://github.com/json-api/json-api/issues/508.
Basically, with /articles/1/relationships/tags response will be object which represents relationship between articles and tags. The response could be something like this (what you put in your question):
{
"links": {
"self": "/articles/1/relationships/tags",
"related": "/articles/1/tags"
},
"data": [
{ "type": "tags", "id": "2" },
{ "type": "tags", "id": "3" }
]
}
This response gives only the necessary data (in primary data attribute - data) to manipulate the relationship and not resources connected with relationship. That being said, you'll call /articles/1/relationships/tags if you want to create new relationship, add a new tag (basically updating relationship) to article, read which tags belong to article (you only need identity to search them on server) or delete article tags.
On the other hand, calling /articles/1/tags will respond with tags as primary data with all the other properties that they have (articles, relationships, links, and other top-level attributes such include, emphasized text, links and/or jsonapi).
They are different. Here is an example from my project.
Try Get http://localhost:3000/phone-numbers/1/relationships/contact you will get response like this:
{
"links": {
"self": "http://localhost:3000/phone-numbers/1/relationships/contact",
"related": "http://localhost:3000/phone-numbers/1/contact"
},
"data": {
"type": "contacts",
"id": "1"
}
}
You didn't get the attributes and relationships which is probably you want to retrieve.
Then
Try Get http://localhost:3000/phone-numbers/1/contact you will get response like this:
{
"data": {
"id": "1",
"type": "contacts",
"links": {
"self": "http://localhost:3000/contacts/1"
},
"attributes": {
"name-first": "John",
"name-last": "Doe",
"email": "john.doe#boring.test",
"twitter": null
},
"relationships": {
"phone-numbers": {
"links": {
"self": "http://localhost:3000/contacts/1/relationships/phone-numbers",
"related": "http://localhost:3000/contacts/1/phone-numbers"
}
}
}
}
}
You can see you retrieved all the information you want, including the attributes and relationships.
But you should know that relationships can be used for some purpose. Please read http://jsonapi.org/format/#crud-updating-to-one-relationships as a sample.