crnk-io/Lobby

Remo

@remmeier

oh, where was that link, it is now crnk-integration-examples. some how them use sevlets. CrnkCoreAutoConfiguration may be a good example as it is also based on servlets. In genereal CrnkSerlvlet gets you in touch with CrnkBook that is shared among all integration.

Aurelien Mazurie

@aurelienmazurie-wk

AFAICT none of the projects in crnk-integration-examples use servlets?

CrnkCoreAutoConfiguration is interesting, thanks!

It doesn't seem to do anything related to resource repositories though, too ba

Remo

@remmeier

indeed, should be changed. had in mind that dropwizard is using it, but that one is based on jaxrs. everything cleared up regarding resource repositories? they can either be registered with a module or through service discovery. spring makes use of the later due to its depenny injection architecture.

Miguel González

@magg

hi guys, is there a way to represent a many to many relationship with @JsonApiRelation ?

Aurelien Mazurie

@aurelienmazurie-wk

I was able to pick up on the module-based declaration of my resource repositories, and that part works. Nice!

Remo

@remmeier

Hi @magg what is your use case? In general many-to-many works well. You just have @JsonApiRelation and a Collection type on both sides. Or @JsonApiRelationId works as well. But given its more complex nature may a custom RelationshipRepository is required. Sometimes I also consider uing two one-to-many relationships with a "join resource" inbetween (similar to JPA/SQL).

Miguel González

@magg

hi @remmeier I have just tested using @JsonApiRelation and a Collection on both sides, and it worked fine. thanks

i have another question though, how can I generate a json as depicted in https://jsonapi.org/format/#crud-updating-resource-relationships Updating a Resource’s Relationships section

Miguel González

@magg

meaning.... filling the relationships objects while doing a patch

Miguel González

@magg

nevermind I found out how, using the same @JsonApiRelation attributes... duh

Remo

@remmeier

ok good!

Enrique Medina Montenegro

@emedina

Hi there! Just started to evaluate JSON:API as compared to Swagger/OpenAPI, but I'm finding difficulties with making the UI work --> http://127.0.0.1:8080/browse/#/

I followed the example for Projects, but I just cannot see anything in the UI

I set this up using --> UIModule.create(new UIModuleConfig()); in my Spring Boot Application code

Any clue anyone what am I missing here?

Remo

@remmeier

Hi, is there an error in the console? Maybe one important difference to swagger, the UI is not stringly necessary. a simple browser is already enough. For example in Firefox one can quite nicely discover/traverse an endpoint (assuming some data is in there). But there is currently also a ticket to refresh the UI a bit: crnk-project/crnk-framework#517

Enrique Medina Montenegro

@emedina

I was referring to the auto-generated UI that allows you to see "graphically" your API and even invoke some endpoints ala "swagger-style"

Remo

@remmeier

yes, what was the errror?

as disclaimer: the UI is still rather basic, that's why there is that other ticket.

Enrique Medina Montenegro

@emedina

Well, if you see my message, there is no error; just sort of no content although I set up the Project endpoint (see the screenshot I pasted)

Remo

@remmeier

is there an error in the console or network traffic?

Enrique Medina Montenegro

@emedina

No, no error whatsoever in either

I see this URL being called --> http://127.0.0.1:8080/meta/resource?sort=resourceType&page[limit]=1000

Remo

@remmeier

is there a result or is it empty as well?

Enrique Medina Montenegro

@emedina

That does have results

This is version 3.0.20190714142556

Remo

@remmeier

I see the issue, if the plain-json module is applied, the UI is not working so far. One has to add the JSON:API content type to the request to receive the data in the JSON:API rather than the simplified format. I will fix that.

Enrique Medina Montenegro

@emedina

Great!

Let me know if you have a new build I can try to test it out and help out here :-)

Remo

@remmeier

latest version 3.1.20190821104834 from http://www.crnk.io/releases/ should be fine

Enrique Medina Montenegro

@emedina

@remmeier Has this been published to some Maven repo?

Cannot resolve it in my project...

Found it --> https://dl.bintray.com/crnk-project/mavenLatest/

Enrique Medina Montenegro

@emedina

Now it's working. Thanks!

Remo

@remmeier

right, every commit to master gets published to that repository. From time to time there is an "official" release.

Luke Horton

@lwhorton

:wave: hey folks. when using crnk is there a way to configure/annotate resource links to not provide related?

i think crnk incorrectly interprets the json:api spec, i.e.:

mandates two relationship links: self, related

but the spec itself actually only mandates self, where related is marked MAY. this is important to us because 1. we find related kind of arbitrary and (potentially) confusing on the human-client side, 2. we want to force traversals of relationships through a relationship resource, and not provide the ability to "short-circuit" a traversal by following a related link

Luke Horton

@lwhorton

related to this, we're finding that the implicitly created relationshipresources via @jsonapirelationid annotations are pretty cool in principal. unfortunately, if you follow the self link for a relationship resource, the resource itself doesn't include a relationships or links identifier. am i misinterpreting the jsonapi spec here? wouldn't it be necessary if you're traversing through a resource A -> relationships to B -> relationshipresource AB -> related resource B for AB to have links to the canonical A and B?

we're starting to dig into custom relationship repository implementations, but before we get deeper into the stack i figured it might save us some time / confusion if someone already has an answer to this :point_up: . thanks!

Remo

@remmeier

Hi @lwhorton not so far, no. Self and related come together. But there is already http://www.crnk.io/releases/latest/documentation/#_payload_size_optimizations. With this in mind, removing the related if really desired would not be too far away. Alternatively you can add a DocumentFilter to strip them out again already today.

I cannot quite follow on the second question, can you give an example how AB would look like? Note that in this area we also have http://www.crnk.io/releases/latest/documentation/#_nested_resources.

Luke Horton

@lwhorton

:thumbsup: . i might have convinced myself to go the other way. i think it's actually a bad idea (for caching, client reliability) for a related link to point to a "canonical" (root?) representation of a resource (such as related: /b/{id for b}. it should actually be an url that points to some /a/{a identifier}/b. if the relationship between a<->b changes, you wouldn't want the related url to change as well... for one case, the related would always and forever remain /a/a-id/b, and in the other case it might change from /b/b-id-1 to /b/b-id-2` which would be really bad for client correctness + caching.

but to answer your question @remmeier , what I would have expected some RelationResourceAB to look like is:

{ 
relationships: { a: { links: self: '/a/1' }}, { b: { links: self: '/b/2' }}, 
links: { self: '/a/1/relationships/b' 
// not really sure what data should/would look like here, maybe this?
data: [{ id: '1', type: 'a' }, { id: '2', type: 'b'}],
// or more likely we don't need or want both identifiers, since the relation is already rooted in a
data: { id: 2, type: 'b' }
}

in this sense, the relationship is just pointing to canonical resources A and B.

Luke Horton

@lwhorton

instead, most implementations I see are something that doesn't make particular sense to me because

they're sometimes only data fields w/ resource identifiers (no links)
when they provide links, it might just be self (theres no way to get back to A or B)
there's never an example of a relationships
sometimes when they provide links, the related points to something like /a/1/b (which is good, a unique url to follow to get the actual B resources), but i would have expected those linkages to be inside relationships

so does this mean it's "proper/okay" for a RelationshipResourceAB to only have

data with resource identifiers of b
links with a self and related, where related points to "here is the URL to follow to get the actual resource(s) b that are currently part of this relationship with a"?

Luke Horton

@lwhorton

( i realize this is crazy deep and contextual, i've just been brewing over it for days and haven't found satisfactory solutions )

Remo

@remmeier

i realize this is crazy deep and contextual

indeed, I may cannot fully follow you yet, but hope I can clear up one or the other thing. I think in general the convetions of JSON:API are rather good and spares you from coming up on solutions of your own on all those things.

if the relationship between a<->b changes, you wouldn't want the related url to change as well...

yes exactly, clients should always be able to fetch the "relationships" throuwh a constant, non-changing URL.

so does this mean it's "proper/okay" for a RelationshipResourceAB to only have data with resource identifiers of b

relationships can be accessed in two ways: /api/A/1/b or /api/A/1/relationships/b. One is the full related resource, whereas the other only the "ids" as belong to the resource.

Where communities thrive

People

Repo info

Activity