Can a JSON API resource have an attribute which is a shorthand for a relationship?Can comments be used in JSON?How can I pretty-print JSON in a shell script?How can I pretty-print JSON using JavaScript?How do I get ASP.NET Web API to return JSON instead of XML using Chrome?Standard JSON API response format?REST API - PUT vs PATCH with real life examplesRepresenting non-resourceful aggregated data with JSON APIAdding attributes to a relationship in Django Rest Framework w/ JSON API FormatJSON API for non-resource responsesRails jsonapi resources “key not found” error on included scoped has_many relationships
How to pronounce the slash sign
Opposite of a diet
What is the best translation for "slot" in the context of multiplayer video games?
Crossing the line between justified force and brutality
I'm in charge of equipment buying but no one's ever happy with what I choose. How to fix this?
Is the destination of a commercial flight important for the pilot?
Purchasing a ticket for someone else in another country?
How to safely derail a train during transit?
Was Spock the First Vulcan in Starfleet?
Did Dumbledore lie to Harry about how long he had James Potter's invisibility cloak when he was examining it? If so, why?
Tiptoe or tiphoof? Adjusting words to better fit fantasy races
How to Reset Passwords on Multiple Websites Easily?
Are student evaluations of teaching assistants read by others in the faculty?
Is exact Kanji stroke length important?
Roman Numeral Treatment of Suspensions
How do I go from 300 unfinished/half written blog posts, to published posts?
A particular customize with green line and letters for subfloat
How do I extract a value from a time formatted value in excel?
How do I find the solutions of the following equation?
How can a function with a hole (removable discontinuity) equal a function with no hole?
How easy is it to start Magic from scratch?
Anatomically Correct Strange Women In Ponds Distributing Swords
For a non-Jew, is there a punishment for not observing the 7 Noahide Laws?
Is there a good way to store credentials outside of a password manager?
Can a JSON API resource have an attribute which is a shorthand for a relationship?
Can comments be used in JSON?How can I pretty-print JSON in a shell script?How can I pretty-print JSON using JavaScript?How do I get ASP.NET Web API to return JSON instead of XML using Chrome?Standard JSON API response format?REST API - PUT vs PATCH with real life examplesRepresenting non-resourceful aggregated data with JSON APIAdding attributes to a relationship in Django Rest Framework w/ JSON API FormatJSON API for non-resource responsesRails jsonapi resources “key not found” error on included scoped has_many relationships
I have a JSON API endpoint for retrieving the user. This resource will also be used to get the permissions of the user, for showing or hiding specific elements in our front end application.
The resource looks like this:
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
"jsonapi":
"version": "1.0"
,
"meta":
"content-type": "application/vnd.api+json"
,
"links":
"self": "/users/some-uuid"
,
"data":
"type": "users",
"id": "some-uuid",
"attributes":
"email": "some-email@example.com",
"permissions": [
"view-all-users",
"view-all-shifts"
]
,
"relationships":
"roles":
"data": [
"type": "role",
"id": "some-role-uuid"
]
The permissions attribute holds the slugs for the permissions that the user has.
If this attribute was not present the front end application would have to include the resources roles and roles.permissions to be able to get to the user's permissions. That response would look like the following:
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
"jsonapi":
"version": "1.0"
,
"meta":
"content-type": "application/vnd.api+json"
,
"links":
"self": "/users/some-uuid"
,
"data":
"type": "users",
"id": "some-uuid",
"attributes":
"email": "some-email@example.com",
"permissions": [
"view-all-posts",
"edit-all-posts"
]
,
"relationships":
"roles":
"data": [
"type": "role",
"id": "some-role-uuid"
]
,
"included": [
"type": "roles",
"id": "some-role-uuid",
"attributes":
"name": "Editor"
,
"relationships":
"permissions":
"data": [
"type": "permission",
"id": "some-permission-uuid"
,
"type": "permission",
"id": "some-permission-uuid-2"
]
,
"type": "permissions",
"id": "some-permission-uuid",
"attributes":
"slug": "view-all-posts"
,
"type": "permissions",
"id": "some-permission-uuid",
"attributes":
"slug": "edit-all-posts"
]
In this case the front end has to do a lot of processing just to get to the permission slugs. My question here is: Is it bad to have a short hand attribute permissions on the user resource like the above example, or should the front end always get to the slugs through the relationships?
Note: In the future we will have an admin interface where the user can manage users, roles and permissions. That is why the roles and permissions are available as seperate entities.
json semantics semantic-markup json-api jsonapi-resources
asked Mar 7 at 12:58
T.A.C. CommandeurT.A.C. Commandeur
17010
add a comment |
I have a JSON API endpoint for retrieving the user. This resource will also be used to get the permissions of the user, for showing or hiding specific elements in our front end application.
The resource looks like this:
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
"jsonapi":
"version": "1.0"
,
"meta":
"content-type": "application/vnd.api+json"
,
"links":
"self": "/users/some-uuid"
,
"data":
"type": "users",
"id": "some-uuid",
"attributes":
"email": "some-email@example.com",
"permissions": [
"view-all-users",
"view-all-shifts"
]
,
"relationships":
"roles":
"data": [
"type": "role",
"id": "some-role-uuid"
]
The permissions attribute holds the slugs for the permissions that the user has.
If this attribute was not present the front end application would have to include the resources roles and roles.permissions to be able to get to the user's permissions. That response would look like the following:
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
"jsonapi":
"version": "1.0"
,
"meta":
"content-type": "application/vnd.api+json"
,
"links":
"self": "/users/some-uuid"
,
"data":
"type": "users",
"id": "some-uuid",
"attributes":
"email": "some-email@example.com",
"permissions": [
"view-all-posts",
"edit-all-posts"
]
,
"relationships":
"roles":
"data": [
"type": "role",
"id": "some-role-uuid"
]
,
"included": [
"type": "roles",
"id": "some-role-uuid",
"attributes":
"name": "Editor"
,
"relationships":
"permissions":
"data": [
"type": "permission",
"id": "some-permission-uuid"
,
"type": "permission",
"id": "some-permission-uuid-2"
]
,
"type": "permissions",
"id": "some-permission-uuid",
"attributes":
"slug": "view-all-posts"
,
"type": "permissions",
"id": "some-permission-uuid",
"attributes":
"slug": "edit-all-posts"
]
In this case the front end has to do a lot of processing just to get to the permission slugs. My question here is: Is it bad to have a short hand attribute permissions on the user resource like the above example, or should the front end always get to the slugs through the relationships?
Note: In the future we will have an admin interface where the user can manage users, roles and permissions. That is why the roles and permissions are available as seperate entities.
json semantics semantic-markup json-api jsonapi-resources
asked Mar 7 at 12:58
T.A.C. CommandeurT.A.C. Commandeur
17010
1
How would the front end know in that case that an update to arolemight changes thepermissionattribute of the user? I'm also not quite sure what you mean by a "log of processing". I would expect that a client of JSON:API uses an implementation that provides a nice interface to access related records. I don't think there is a performance difference relevant for any real world usage example. Response body size is a little bit higher for a single resource but that shouldn't be relevant after gzip and may even be less for collections.
– jelhan
Mar 7 at 23:46
add a comment |
I have a JSON API endpoint for retrieving the user. This resource will also be used to get the permissions of the user, for showing or hiding specific elements in our front end application.
The resource looks like this:
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
"jsonapi":
"version": "1.0"
,
"meta":
"content-type": "application/vnd.api+json"
,
"links":
"self": "/users/some-uuid"
,
"data":
"type": "users",
"id": "some-uuid",
"attributes":
"email": "some-email@example.com",
"permissions": [
"view-all-users",
"view-all-shifts"
]
,
"relationships":
"roles":
"data": [
"type": "role",
"id": "some-role-uuid"
]
The permissions attribute holds the slugs for the permissions that the user has.
If this attribute was not present the front end application would have to include the resources roles and roles.permissions to be able to get to the user's permissions. That response would look like the following:
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
"jsonapi":
"version": "1.0"
,
"meta":
"content-type": "application/vnd.api+json"
,
"links":
"self": "/users/some-uuid"
,
"data":
"type": "users",
"id": "some-uuid",
"attributes":
"email": "some-email@example.com",
"permissions": [
"view-all-posts",
"edit-all-posts"
]
,
"relationships":
"roles":
"data": [
"type": "role",
"id": "some-role-uuid"
]
,
"included": [
"type": "roles",
"id": "some-role-uuid",
"attributes":
"name": "Editor"
,
"relationships":
"permissions":
"data": [
"type": "permission",
"id": "some-permission-uuid"
,
"type": "permission",
"id": "some-permission-uuid-2"
]
,
"type": "permissions",
"id": "some-permission-uuid",
"attributes":
"slug": "view-all-posts"
,
"type": "permissions",
"id": "some-permission-uuid",
"attributes":
"slug": "edit-all-posts"
]
In this case the front end has to do a lot of processing just to get to the permission slugs. My question here is: Is it bad to have a short hand attribute permissions on the user resource like the above example, or should the front end always get to the slugs through the relationships?
Note: In the future we will have an admin interface where the user can manage users, roles and permissions. That is why the roles and permissions are available as seperate entities.
json semantics semantic-markup json-api jsonapi-resources
asked Mar 7 at 12:58
T.A.C. CommandeurT.A.C. Commandeur
17010
I have a JSON API endpoint for retrieving the user. This resource will also be used to get the permissions of the user, for showing or hiding specific elements in our front end application.
The resource looks like this:
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
"jsonapi":
"version": "1.0"
,
"meta":
"content-type": "application/vnd.api+json"
,
"links":
"self": "/users/some-uuid"
,
"data":
"type": "users",
"id": "some-uuid",
"attributes":
"email": "some-email@example.com",
"permissions": [
"view-all-users",
"view-all-shifts"
]
,
"relationships":
"roles":
"data": [
"type": "role",
"id": "some-role-uuid"
]
The permissions attribute holds the slugs for the permissions that the user has.
If this attribute was not present the front end application would have to include the resources roles and roles.permissions to be able to get to the user's permissions. That response would look like the following:
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
"jsonapi":
"version": "1.0"
,
"meta":
"content-type": "application/vnd.api+json"
,
"links":
"self": "/users/some-uuid"
,
"data":
"type": "users",
"id": "some-uuid",
"attributes":
"email": "some-email@example.com",
"permissions": [
"view-all-posts",
"edit-all-posts"
]
,
"relationships":
"roles":
"data": [
"type": "role",
"id": "some-role-uuid"
]
,
"included": [
"type": "roles",
"id": "some-role-uuid",
"attributes":
"name": "Editor"
,
"relationships":
"permissions":
"data": [
"type": "permission",
"id": "some-permission-uuid"
,
"type": "permission",
"id": "some-permission-uuid-2"
]
,
"type": "permissions",
"id": "some-permission-uuid",
"attributes":
"slug": "view-all-posts"
,
"type": "permissions",
"id": "some-permission-uuid",
"attributes":
"slug": "edit-all-posts"
]
In this case the front end has to do a lot of processing just to get to the permission slugs. My question here is: Is it bad to have a short hand attribute permissions on the user resource like the above example, or should the front end always get to the slugs through the relationships?
Note: In the future we will have an admin interface where the user can manage users, roles and permissions. That is why the roles and permissions are available as seperate entities.
json semantics semantic-markup json-api jsonapi-resources
json semantics semantic-markup json-api jsonapi-resources
asked Mar 7 at 12:58
T.A.C. CommandeurT.A.C. Commandeur
17010
asked Mar 7 at 12:58
T.A.C. CommandeurT.A.C. Commandeur
17010
asked Mar 7 at 12:58
T.A.C. CommandeurT.A.C. Commandeur
17010
asked Mar 7 at 12:58
T.A.C. CommandeurT.A.C. Commandeur
17010
asked Mar 7 at 12:58
T.A.C. CommandeurT.A.C. Commandeur
17010
17010
1
How would the front end know in that case that an update to arolemight changes thepermissionattribute of the user? I'm also not quite sure what you mean by a "log of processing". I would expect that a client of JSON:API uses an implementation that provides a nice interface to access related records. I don't think there is a performance difference relevant for any real world usage example. Response body size is a little bit higher for a single resource but that shouldn't be relevant after gzip and may even be less for collections.
– jelhan
Mar 7 at 23:46
add a comment |
1
How would the front end know in that case that an update to arolemight changes thepermissionattribute of the user? I'm also not quite sure what you mean by a "log of processing". I would expect that a client of JSON:API uses an implementation that provides a nice interface to access related records. I don't think there is a performance difference relevant for any real world usage example. Response body size is a little bit higher for a single resource but that shouldn't be relevant after gzip and may even be less for collections.
– jelhan
Mar 7 at 23:46
1
1
How would the front end know in that case that an update to a
role might changes the permission attribute of the user? I'm also not quite sure what you mean by a "log of processing". I would expect that a client of JSON:API uses an implementation that provides a nice interface to access related records. I don't think there is a performance difference relevant for any real world usage example. Response body size is a little bit higher for a single resource but that shouldn't be relevant after gzip and may even be less for collections.– jelhan
Mar 7 at 23:46
How would the front end know in that case that an update to a
role might changes the permission attribute of the user? I'm also not quite sure what you mean by a "log of processing". I would expect that a client of JSON:API uses an implementation that provides a nice interface to access related records. I don't think there is a performance difference relevant for any real world usage example. Response body size is a little bit higher for a single resource but that shouldn't be relevant after gzip and may even be less for collections.– jelhan
Mar 7 at 23:46
add a comment |
1 Answer
1
active
oldest
votes
Client apps can easily merge all the permissions from roles into one key/array themselves and work from there. This way you'll keep the principles of JSON API in tact and give the client apps the freedom to work with permissions as they prefer.
answered Mar 11 at 8:25
Rick SlijkhuisRick Slijkhuis
1
1
You might want to rephrase or answer more precisely with a solution to this very problem. You're stating that this is easily solvable without posting a proper example or solution.
– bastianwegge
Mar 11 at 8:46
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55044378%2fcan-a-json-api-resource-have-an-attribute-which-is-a-shorthand-for-a-relationshi%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Client apps can easily merge all the permissions from roles into one key/array themselves and work from there. This way you'll keep the principles of JSON API in tact and give the client apps the freedom to work with permissions as they prefer.
answered Mar 11 at 8:25
Rick SlijkhuisRick Slijkhuis
1
1
You might want to rephrase or answer more precisely with a solution to this very problem. You're stating that this is easily solvable without posting a proper example or solution.
– bastianwegge
Mar 11 at 8:46
add a comment |
Client apps can easily merge all the permissions from roles into one key/array themselves and work from there. This way you'll keep the principles of JSON API in tact and give the client apps the freedom to work with permissions as they prefer.
answered Mar 11 at 8:25
Rick SlijkhuisRick Slijkhuis
1
1
You might want to rephrase or answer more precisely with a solution to this very problem. You're stating that this is easily solvable without posting a proper example or solution.
– bastianwegge
Mar 11 at 8:46
add a comment |
Client apps can easily merge all the permissions from roles into one key/array themselves and work from there. This way you'll keep the principles of JSON API in tact and give the client apps the freedom to work with permissions as they prefer.
answered Mar 11 at 8:25
Rick SlijkhuisRick Slijkhuis
1
Client apps can easily merge all the permissions from roles into one key/array themselves and work from there. This way you'll keep the principles of JSON API in tact and give the client apps the freedom to work with permissions as they prefer.
answered Mar 11 at 8:25
Rick SlijkhuisRick Slijkhuis
1
answered Mar 11 at 8:25
Rick SlijkhuisRick Slijkhuis
1
answered Mar 11 at 8:25
Rick SlijkhuisRick Slijkhuis
1
answered Mar 11 at 8:25
Rick SlijkhuisRick Slijkhuis
1
1
1
You might want to rephrase or answer more precisely with a solution to this very problem. You're stating that this is easily solvable without posting a proper example or solution.
– bastianwegge
Mar 11 at 8:46
add a comment |
1
You might want to rephrase or answer more precisely with a solution to this very problem. You're stating that this is easily solvable without posting a proper example or solution.
– bastianwegge
Mar 11 at 8:46
1
1
You might want to rephrase or answer more precisely with a solution to this very problem. You're stating that this is easily solvable without posting a proper example or solution.
– bastianwegge
Mar 11 at 8:46
You might want to rephrase or answer more precisely with a solution to this very problem. You're stating that this is easily solvable without posting a proper example or solution.
– bastianwegge
Mar 11 at 8:46
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55044378%2fcan-a-json-api-resource-have-an-attribute-which-is-a-shorthand-for-a-relationshi%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
How would the front end know in that case that an update to a
rolemight changes thepermissionattribute of the user? I'm also not quite sure what you mean by a "log of processing". I would expect that a client of JSON:API uses an implementation that provides a nice interface to access related records. I don't think there is a performance difference relevant for any real world usage example. Response body size is a little bit higher for a single resource but that shouldn't be relevant after gzip and may even be less for collections.– jelhan
Mar 7 at 23:46