Missing Views link relationships when Views UI installed

Copying part of my comment from #2571235-102: [regression] Roles should depend on objects that are building the granted permissions

[This is exposing] some fundamentally odd things about entity link templates: They use link relation types as their keys and REST is automatically trying to expose them.

[This forces us to add some pretty pointless link relation types.] What does an edit-display-form link relation type even mean to a REST client? In 99% of cases, that serialization format is going to be JSON/XML, not HTML, and neither of these media types define form semantics like HTML does.

IMHO, we shouldn't be adding Link headers to REST responses for every link template. Especially if a matching link relation type is not defined for it. All that does is create a noisy and poor DX for anyone using REST. Worse, our extension link relation types are not even valid.

The attached removes the assumption that every link template has an associated link relation type. I think we should do something to this effect and then define some follow-ups to disassociate them everywhere else.

Instead of adding Link headers for every link template, we should be adding them for every link template with a defined link relation type and then follow that up by removing link relation types that don't make sense in the REST use-case.

While I agree with the questionability of the design choice that was made for the REST module (@gabesullice++), I think that it makes more sense to be consistent about our current approach rather than starting to deviate from it (@alexpott++).

What does an edit-display-form link relation type even mean to a REST client? In 99% of cases, that serialization format is going to be JSON/XML, not HTML, and neither of these media types define form semantics like HTML does.

It's possible that in the case of a decoupled UI, you want to be able to link to the edit-display-form. You're right that in that case the client would be bridging between an API-consumption context and a HTML-UI context. That's odd. But it's the vision that was behind the original REST architecture, and in principle it allows a gradual creation of a decoupled admin UI.

You're right that the current implementation violates the letter of the spec with regard to extension link relation types, that's indeed why I created #2848945: EntityType link templates: using link relation type names as keys is a problem. But that doesn't make it any less usable in practice.

Long story short: I think this is not the time or place to start deviating from the principle for the REST module that was established a long time ago. That requires a longer discussion, specifically dedicated to that scope. This issue is just a bugfix to ensure all REST resources behave consistently.

Fair enough.

Fixed on commit

diff --git a/core/modules/views_ui/views_ui.link_relation_types.yml b/core/modules/views_ui/views_ui.link_relation_types.yml
index ebc970ae53..4fa4015239 100644
--- a/core/modules/views_ui/views_ui.link_relation_types.yml
+++ b/core/modules/views_ui/views_ui.link_relation_types.yml
@@ -2,7 +2,7 @@
 # See https://tools.ietf.org/html/rfc5988#section-4.2.
 edit-display-form:
   uri: https://drupal.org/link-relations/edit-display-form
-  description: A form where a view display can be editted.
+  description: A form where a view display can be edited.
 preview-form:
   uri: https://drupal.org/link-relations/preview-form
   description: A form where a view display can be previewed.

Committed 34c888b and pushed to 9.0.x. Thanks!

Backported to 8.9.x