[Data Object Editor] Quantity value endpoints tag handling

[markus-moser]

• Please use a different tag then "Class Definition" - it should be a separate tag specialized for the units
• The convert and convert all endpoints should not invalidate any tag as they do not change data. Otherwise RTK query automatically refreshes the local unit list when calling these methods.

[markus-moser]

part of #566

[lukmzig]

• The convert and convert all endpoints should not invalidate any tag as they do not change data.

@markus-moser I do not get what you mean? Tag in what context? These methods are calling convert method from the core service, same as in the classic UI.
https://github.com/pimcore/studio-backend-bundle/blob/1.x/src/Class/Service/QuantityValueService.php#L147

[markus-moser]

@lukmzig It's about the tags in the schema:

We should change it for the GET request to something different and remove it for the post requests to something different as otherwise the POST requests invalidates the GET request although the data does not change.

[lukmzig]

@lukmzig It's about the tags in the schema:

We should change it for the GET request to something different and remove it for the post requests to something different as otherwise the POST requests invalidates the GET request although the data does not change.

Are you invalidating the tags for all POST requests?? then we can change the convert requests to GET ... tags are for us only for the categorization, if you are using them for different purposes please share this information in the future ....

[markus-moser]

@lukmzig "We" do not do this, this is the default behaviour of RTK query for all endpoints. As the API is generated out of the schema RTK handles it like this by default. If it is hard to solve this on your side then let's override the API in the frontend and enrich the tag logic there, that's fine. I would not change it to a POST.

[lukmzig]

@lukmzig "We" do not do this, this is the default behaviour of RTK query for all endpoints. As the API is generated out of the schema RTK handles it like this by default. If it is hard to solve this on your side then let's override the API in the frontend and enrich the tag logic there, that's fine. I would not change it to a POST.

Convert endpoints are already a POST request right? So then we should rather change the convert requests to GET so we avoid any overriding. We can still use a separate tag as well.

[markus-moser]

@lukmzig Yes, in general GET is the better choice, currently the convert endpoints are POST

[mattamon]

@markus-moser the method type really depends on what it does in the system.
Since this is an API we should stick to the common CRUD rules.

If you change something on the server it is POST or PUT.

We should not change this solely based on some implementation details in FE, since Studio Backend can be used without FE too.

[markus-moser]

@mattamon I agree, but the convert endpoints do not change anything. So it's not a implementation detail in the frontend.

[lukmzig]

@markus-moser its changed now, please adapt the route in FE accordingly

[markus-moser]

@lukmzig Thanks, I updated in the FE and it works well now 👍