API to enable / disable links property per entity resource type.

In the specs it's not stated anywhere that they are a required property on all objects at all.

That is true, however there is strong consensus on the JSON:API team to require this in the Drupal implementation.

This started as JSON:API Extras issue, but due to complexity in how can that be overwritten from there, here we are :)...

We should move this back to the JSON:API Extras issue queue and work on the implementation. I suspect the "new" links collector can be used for this. Just like jsonapi_hypermedia can add links we should be able to remove them. JSON:API Extras will be the place to add the configuration (a single on/off toggle for all resource types, like the count feature).

my total payload for a node (by ID) resource page dropped by about ~33%: 364 -> 246 kb (plain)

How much difference is there with gzip or brotli enabled?

Just like jsonapi_hypermedia can add links we should be able to remove them

Exactly. For this use case, I think we can have a jsonapi_hypomedia module? 😆 (hyper vs hypo).

#10: interesting, that's bigger than I thought. Thanks for letting us know!

Hi!

I attach a patch, which provides possibility to enable / disable "links" objects per resource.

However a top level "links" remains a part of the response.
I think enable / disable option for optional top level elements like "links" and "jsonapi" should be in another configuration, which would be more general. Imho such configuration should be on `admin/config/services/jsonapi/extras` page with path prefix settings.

Here is an updated patch. I forgot to hide "links" checkbox on the configuration form, when a source is disabled.

And yes, Nikolay, I understand, that this patch doesn't make influence on the data generating performance.
But as it was mention in #8 comment, this is "a consensus on the JSON:API team to require this in the Drupal implementation".
So the only thing what we can do (without changing jsonapi module itself) is to play with the response view.

And I find the response less messy without all those links. Especially when it's read only endpoint.

I'm inclined towards allowing this. It seems a big enough difference to justify the downsides.

@ndobromirov is on point. I'd like to explore more before going for the second best solution (#18), which will provide a tangible win. Do you think we can decorate the link collector service to avoid generating the configured links? If not, do you think we can modify the collector to make this behavior possible? If we do that we can avoid generating the links in the first place.

I'm inclined towards allowing this. It seems a big enough difference to justify the downsides.

@ndobromirov is on point. I'd like to explore more before going for the second best solution (#18), which will provide a tangible win. Do you think we can decorate the link collector service to avoid generating the configured links? If not, do you think we can modify the collector to make this behavior possible? If we do that we can avoid generating the links in the first place.

but at the moment I will work toward a patch with the setting on the resource types that will manage the isLocatable flag and from there integrate that into the configurable resource type altogether

Any progress on this? :)

I re-rolled the patch in #7 for 9.2

I think actually this is better handled in core, if we have @bbrala's attention on this issue. See related.

Are there still any arguments left to have a switch in core to remove all links and their respective generation, if the use case do not need them? Even if the Drupal Json:Api Core team has a strong standing for providing these links in the output, if the individual website services don't need them, why generating and outputting them against their will and need? It seems like we "fight" over an optional JSON:API Refernece feature which will require only a few if conditions here and there.

I stumbled across this 4 years old issue, because I also want to remove them for our vue app. https://www.drupal.org/project/jsonapi_extras/issues/3311150

@ro-no-lo My understanding is that the reason the links are included without any option to remove them is because that is what is required by the formal JSON:API specification, and the core module aims to provide 100% support for the specification. (See this comment in response to my question about removing links for NULL entity references.)

I understand the case for forcing the links always (if you say the module adds support for a specification, it should follow that specification), but at the same time, your use case and mine could really benefit from slimming down the responses by removing the links, and I am sure there are other sites in the same boat. So even if it violates the specification, I think this would be a very useful option.

I think this feature is often an anti-pattern. I am not very supportive of promoting this practice. Lack of usage of hypermedia capabilities is one of the biggest factors in maintenance problems in decoupled applications.

If your server is using a compression algorithm the difference in the response length should be negligible. If not, that will be a way bigger win across the board than removing some links in JSON:API responses.

That being said, I will defer final decision to @bbrala.

Also note that the initial report was created before we improved internal caching of normalizations, so the generation of links should not be as big of a problem nowadays. Can anyone corroborate this?

I agree with @e0ipso.

If you want to modify all JSON:API responses to not contain any links, that's easy enough to achieve:

1. create a new jsonapi_linkless contrib module
2. add a KernelEvents::RESPONSE event subscriber that runs after jsonapi.resource_response.subscriber (which has priority 128), with a priority lower than Dynamic Page Cache's (100), to ensure the results are cached by Dynamic Page Cache — so any priority in the [101, 127] range.
3. omit all links from the response in that event subscriber, if the response is a JSON:API response

@ptmkenny: The jsonapi.org states that the resource links are optional. https://jsonapi.org/format/#document-resource-object-links

@e0ipso: currently we develop a vue3 app and these modern app come with a lot of packt vuex stores. With more and more entities loaded into the browser system everything grows. I do not have enough expertise to know what will happen, when every call to the json:api and lists of entities come with a 30% overload of unused data. We may be not experienced enough to build such a hypermedia usage into the system, but thats were we are currently. My concern is, that the memory usage is growing for processing the JSON responses from the server, even though it could be smaller. Time will tell.

@wim-leers: Thanks for the tipp. I will consider it, when we run into memory problems.

My concern is, that the memory usage is growing for processing the JSON responses from the server

I think this may not be a problem as per #31.

currently we develop a vue3 app and these modern app come with a lot of packt vuex stores. With more and more entities loaded into the browser system everything grows. I do not have enough expertise to know what will happen, when every call to the json:api and lists of entities come with a 30% overload of unused data. We may be not experienced enough to build such a hypermedia usage into the system, but thats were we are currently.

I understand that, and I empathise with the situation. However, as a maintainer this is not something I want to prioritize in this module. But, again, I will follow what @bbrala decides since he is carrying the baton of this module.

For everybody interested. I managed to put a module together with the hints Wim Leers gave me. https://www.drupal.org/project/jsonapi_links If you find stuff you could optimize, do so and create a merge request.

26 and 18 are not applying to drupal version 9.5 for me

Re-roll of #14 for D9.5.8.

Thanks for all the contributions! It sounds like ro-no-lo provided a successful solution to this in #35.

Closing.