search

mrichar1 / pinia-jsonapi

Use a JSONAPI api with a Pinia store, with data restructuring/normalization. Topics
GNU Affero General Public License v3.0
8 stars 2 forks source link

Unnecessary request after patchRelated #6

Open mdrews21 opened 2 months ago

mdrews21 commented 2 months ago

After successful patchRelated-action the package calls a GET action on our api (e.g. "tags" of a product)

grafik

  1. problem: We are using modules so our api urls look like "/api/v1/production/products/{id}". The package calls GET "api/v1/products/{id}" after and I don't see a way to change the url of this second api call.
  2. problem: the second api call GET sets parameter "include={relationshipname}". In backend I have to explicitly allow included parameter for every relationship. This is not useful
  3. problem: the GET Action is not necessary because we are already including the relationship resources in the response of the PATCH request

In my opinion it is better to completely disable the GET action after patchRelated, or disable it via config

mrichar1 commented 2 months ago

Hi,

Thanks for opening this issue. The reason why there is an additional GET after PATCH/POST/DELETE operations is twofold.

Firstly, while the JSONAPI standard says that the 200 response can be empty if the server-side changes directly matches the PATCH. However many servers get this wrong, returning empty data when in fact something else is changed server-side. So this GET ensures the client is synced with the server.

Secondly, the PATCH object will only contain 'one side' of any patched relationships. In most cases it is easier to just GET any related items (via includes) after the PATCH, than try to walk the patched relationships locally and manually update the store.

It is currently possible to turn off the following of includes by setting relatedIncludes to false in the config (so it will only get the 'main' object).

However you are right that it should be the case that there should be a way to disable this GET via a config option, so I'll look at adding one in.

Finally if it is left enabled then it should probably prefer the self url in links and fall back to building it from type and idonly if it's missing.

mrichar1 commented 2 months ago

I've added this functionality as a config option called getAfterWrite - this defaults to true but if you set it to false it should do what you need.

(The URL used in the GET is also now the self link url which should fix the issue if your paths aren't /type/id)

Let me know if you have any problems with this - released as 6.6.0.