What benefit are you seeing in modeling the owner as an attribute using a complex type rather than as a separate resource type person having an owner relationship with the group?
There are many drawbacks if not using a separate resource type. E.g. you can not express on API level if multiple groups share the same owner. You would not only duplicate the owner information in the payload. You would also require clients to detect that it is the same person using API-specific logic. Also fetching all groups owned by a specific person would be more challenging. Instead of requesting the person including the groups owned by them (e.g. GET /person/2?include=ownedGroups), a client would need some API-specific filtering logic (e.g. GET /groups?filter[owner.id]=2).
All in all, I highly recommend using separate resource types unless 1) you have very good reasons against doing so and 2) are well aware of the trade-offs - especially for scaling over time with changing business requirements.
Hi, thanks for your answer,
Yes I also prefere the relationship/include solution of “owner” always
My service “group” depends on the service “person” which holds as responsible “core service” my “owner” relationship as type:persons, should my service export this extern type “persons” as owner in relationship and included? In included I will only export my part data of “persons” ( data which are interesting only in context of group)
Is this supported by json:api ? Can relationships and includes also contain part information from other services?
Not sure if I fully understand your question. Looking at API layer the data source is an implementation detail of the server. It could be a database, another service, a connected hardware device or whatever. It’s also an implementation detail of the server if additional data is available, which is not exposed over the API.
To avoid coupling of the microservices you could decide to not support inclusion of those related data. Instead you could provide related resource links for that relationship only. And have the other microservice which owns the data implement those routes. Bit that comes with trade-offs of 1) not supporting inclusion of related resources, 2) not supporting filtering by those related resources, and 3) not supporting sorting by those related resources.
My service “group” store part information of service “persons” as “owner” of group in this model (name, position, surname). So I can filter and sort by owner details.
Both services communicate asynchron ( kafka events)
The use case : my api “group” has to export name , surname… of owner in response of group… Filter and sort are necessary too.
Therefore I have to response owner information in response of group.
The “owner” of group is only one detail in my model.
Can I export my part information of owner in my included? Should I use extern “persons” type and id in relationships or should I create own type and id of my owner in context of group? Maybe eventually the person “owner” in context of group store other special information…which are only relevant in context of group…
Can I export my part information of owner in my included?
Yes. Unless the client requests a specific subset of fields using the fields query parameter family, a server is free to response with a subset of fields:
If a client does not specify the set of fields for a given resource type, the server MAY send all fields, a subset of fields, or no fields for that resource type.
I would recommend highlighting that in your API documentation. Returning a sparse fieldset by default is often unexpected by consumers of an API.
Should I use extern “persons” type and id in relationships or should I create own type and id of my owner in context of group? Maybe eventually the person “owner” in context of group store other special information…which are only relevant in context of group…
That’s up to you. In any case I would recommend 1) having a well-defined relationship between group and person and 2) avoid data duplication (from consumer perspective).
Even if you go with an interim resource type (e.g. groupOwner) holding information relevant for the relationship between a group owner and a person, I would still recommend avoiding duplicating any data from the person resource type on it. Such data duplication introduces many challenges when it comes to caching. It likely causes data inconsistency issues in the long-term. E.g. a client may not be aware that a groupOwner entry in client-side cache must be invalidated whenever the name attribute of a person changes, which is related to that groupOwner.
