-
Notifications
You must be signed in to change notification settings - Fork 14
support iri identification #119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
support iri identification #119
Conversation
Hey @wildhaber, thanks for the kind words ❤️ Interesting and well-explained issue. I think I'm good with this, though I want to get @wadetandy's thoughts first. |
@wildhaber Great issue description. I think this is a good feature to add, but from a performance and general debuggability perspective, instead of inspecting each incoming ID for whether it's following that convention (especially since who knows what crazy other ID patterns might be out there), I'd propose instead adding a static configuration flag that can be checked: class ApplicationRecord extends JSORMBase {
static usesFullPathIds = true // or something. open to suggestions on this
} Then instead of inspecting each incoming id, the |
@wadetandy / @richmolj - thanks for your really quick response 👍 I've discussed this issue with a colleague of mine and I would like to share our key takeaways. Confusion about terminology "resource"I was a bit confused about what a resource is, in terms of JSON API. And was insecure if API-Platform is compliant with the specification. Especially in this part:
After reading the thread resource vs entity where it became clear to me, that Who knows how to transform the path?In our understanding, the only player that knows how to transform the type and id into a URL is the model. Since this might vary if for example the client consumes JSON API resources from different API's. So we had the idea of introducing a new, but optional static resourceTransformer: ((id?: string | number) => string) | undefined So there is just a quick check necessary in the Looking into an example of a JSON API resource like this: // example from: https://demo.api-platform.com/books
{
"data": {
"id": "/books/20",
"type": "Book",
"attributes": {
"isbn": "9780530239033",
"title": "Iste modi accusantium autem suscipit quia et et dolorum.",
"description": "Desc updated",
"author": "Roslyn Morissette",
"publicationDate": "2002-09-08T00:00:00+00:00"
}
}
} the jsorm model would look like: {
static: {
jsonapiType: 'Book',
resourceTransformer(id) {
return id || '/books';
}
},
attrs: {
isbn: attr(),
title: attr(),
description: attr(),
author: attr(),
publicationDate: attr(),
}
} This approach also allows to use the regular MiscDefine a global settings
|
Thanks for all of this detail. A lot to parse, so forgive me if I misunderstand anything. I think what you're suggesting is that the only change should be to support The functionality you're describing is essentially how the library already works, but throws out the inheritance features that are already provided by typescript/javascript. You can simply override the
I could achieve the same thing right now by swapping out
Your patch in https://github.com/echonovum/jsorm/pull/2 is saying "if this method is defined, call it instead and short circuit this behavior", which is exactly what you'd get if you overrode the Please let me know if this works, and if so, help me to identify what if anything we can do to improve here. |
hey @wadetandy , Thanks for your response, yes, this is exactly what I was trying to achieve. Since I'm not really familiar with typescript I was not aware that it works that way. I will give the overriding a try next week and let you know if this is already enough 👍 The only thing that is a difference, is that the model now needs to be aware of the "base path" while the approach with the extra |
Hi,
First of all I want to mention how much I appreciate your work. It makes working with JSON API resources a real pleasure.
In our project, we are using API-Platform to expose the API and consume them in a vue.js app.
API-Platform is exposing the
id
of a JSON API resource in the format of a relativeIRI
Internationalized Resource Identifier. In the end a JSON API resource looks like that:Which is, as far as I understand the JSON API specs, totally valid.
(https://jsonapi.org/format/#document-resource-object-identification)
The small dilemma with IRI's are, when in the next part of the specifications:
In fact, the upper statement could result in a no-go of using IRI's in JSON API. But since we were not able to transform the URL in the middleware (See: #110) we made a small change of the URL-Method to support both formats
{type}/{id}
as well as{iri}
.This small change does not break the strict implementation of JSON API specs at all, but simplifies the integration of other popular frameworks like API-Platform.
Hope this PR would support the jsorm framework.
Keep up the great work 👍