It's not quite clear to me how this should behave for POST requests.

If X is a redirect to Y, and GET request for X would redirect to Y. What should a POST or PUT request to X do? Fail unless redirect=false is given? Or just edit X?

Note that the redirects functionality in RESTBase has some known bugs as well. There are the following separate aspects to how redirects "should" work:

1. Ordinary mediawiki title munging (space to underscore and all the rest) which is done by the JS mediawiki-title library and is itself quite complex; but is thankfully standalone with some independent implementations. This usually comes "for free" when done in core, but requires an explicit redirect if you don't want edge caching to store multiple copies of the same content.

2. [[#REDIRECT]] processing: Parsoid actually returns an HTML document for the redirect page, so this is "easy" to do in a decoupled manner for Parsoid endpoints, but for non-parsoid endpoints this requires a separate interaction w/ core to resolve.

3. Language converter title munging: if the requested title is missing, it is language converted and if the converted title is present it is treated as a redirect. (I think there /might/ be multiple levels of this with language variant fallback chains.) I have a partial reimplementation of language converter in a language-independent FST but we've never really resolved whether we're going to move to that. If we don't have an independent implementation, this has to be resolved via a request to core for services which aren't implemented in core. See T257965: [Bug] page/summary and page/mobile-html do not handle specific redirect titles correctly and T277059: [Bug] Blue links are broken on the Serbian (Latin) Burek article on iOS and Android for some examples of the issues here.

4. Flagged revisions -- once we have the title we need a revision on that title, and flagged revisions can affect that. Not only that, but your user identity determines which revision you get, since a user can see their own revisions even if they haven't been flagged. (But when you're requesting content for editing you probably want to bypass the flagged revision and always use the latest revision, to avoid conflicts?) T209936: Content of unaccepted pending revisions show up in RESTBase APIs and T218090: Extension:FlaggedRevs can't control which revision is used on API action=parse calls. are related.

5. Not really investigated, but the Translate extension also hooks the title lookup mechanism, so that a request for [[Template:Foo]] will get [[Template:Foo/de]] in some cases: T47096: Add a way to transclude template or other page in the correct language. Presumably requests for [[Foo]] should also go to [[Foo/de]] on multi-language wikis where the user's language is set to de.

I guess my bottom line here is that this lookup/redirect mechanism is surprisingly complex and probably needs to be yoinked out of "restbase" and put back into core. All of the APIs which "only take a title" need to be refactored to take a revision ID instead, and then the title->revision ID lookup handled consistently (with appropriate options for "my flagged revision userid is X" and "my user language/variant is Y" which can affect the lookup). If this mapping is cached somewhere, then the cache needs to be invalidated when new pages are added (which can be language converted or translated versions of pages you looked up) and when flagged revisions change.

This would also fix @daniel's issues with POST above as well: the POST should always be to a specific revision ID and the title->revision mapping should be completely separated out from any POST API.

Global user pages are another instance which *perhaps* should be handled via the generic redirect service, despite the title of this task: T153801: File and global user pages should not be redirected. (I think the title is mostly referring to the fact that the language settings should be taken into account when the redirect is done, which was mentioned in the comment above.)

Pro:

• an HTML 302 redirect can easily handle cross-domain redirects, ie en.wikipedia.org/..../revision/for/User:cscott redirecting to mediawiki.org/page/html/User:cscott

Con:

• perhaps this is really more like a /transclusion/ than a /redirect/? I don't know if Parsoid's current DOM spec has a way to denote a cross-wiki transclusion though...

See also T51097#7401266 which discusses transclusion of file description pages from commons.