To access REST export views, one now MUST specify a ?_format=… query string

Creating a "REST export display" (e.g. JSON) for a view at the same URL as a "Page display" (HTML) would result in the Page display (HTML) being completely inaccessible.

The root cause was a debugging nicety that was added in #1969870: REST export view should default to JSON, which had this unfortunate side effect. (It was done for the sake of simplifying debugging… because people found it too hard to specify an Accept request header (back when Drupal still did Accept header based content negotiation).)

The solution is simple: always specify ?_format=json, ?_format=csv, ?_format=SOMETHING! That should already have been the case, but due to this debugging nicety you may have been misled to think that this was guaranteed to continue to work the same way.

Before

https://example.com/some-listing

After

https://example.com/some-listing?_format=json

What if I have clients that hardcode https://example.com/some-listing before we can update them?

Set up a redirect in either PHP code, your web server (e.g. Apache's .htaccess) or your reverse proxy. Redirect them from /some-listing to /some-listing?_format=json. This then effectively hardcodes this mapping. (Drupal cannot make this assumption for you, but you can!)

Why can't this work automatically for views that have a REST export display with a single format and without a page display?

In this case and only in this case, it could indeed be done automatically. A core bug stands in the way of that: #2854543: NegotiationMiddleware calls $request->setRequestFormat('html') when there is no _format request parameter, but shouldn't. Chime in to help fix it.

However, if at some point in the future you add a page display or you add a new format to the REST export display, you'll still face the same update path: you'll still have to ensure you specify ?_format=…!