Change Details

For feature parity with RESTBase, core HTML REST routes should follow redirects. WE should respond with 302 status code and a `Location` header for the redirect target. We can also include the redirect page HTML in the body of the response - non-browser API clients will be able to read it. For VisualEditor, when we actually want to edit the redirect page itself, restbase supports `?redirect=false` query parameter. Core should do the same.

For feature parity with RESTBase as well as with index.php, the `v1/page/{title}` endpoint should follow redirects. We should respond with 30x status code and a `Location` header for the redirect target. Note that there are different categories of redirects that we may have to distinguish: == Wiki Redirects == Wiki redirects are defined explicity using the `#REDIRECT` syntax. Following these should be enabled per default, but can be disabled using `redirect=false`. index.php does this, and the RESTbase endpoitns do this. We can also include a representation of the redirect in the body of the response - non-browser API clients will be able to read it. Note that the representation may be in JSON, HTML, or JSON and HTML, depending on whether the request was made to `v1/page/{title}`, `v1/page/{title}/html` or `v1/page/{title}/with_html`. == Normalization Redirects == Normalization redirects happen when the Title requested isn't the canonical one. We should only serve content from the canonical title. Title normalization includes: * Converting the first letter to upper-case and converting spaces to underscores. * Normalizing unicode, resolving spurious HTML or URL encoding * Applying variant conversion The redirect itself should be permanent and cacheable. == Revision Redirects == We could always redirect from the `v1/page` endpoint to the `v1/revision` endpoint for the current revision (or the current flagged revision?). But that really only makes sense for `v1/page/{title}/html`. Would it be confusing if we don't do it for the metadata endpoing `v1/page/{title}`? Also, should the redirect be cacehable? It will need purging...

For feature parity with RESTBase as well as with index.php, core HTML REST routesthe `v1/page/{title}` endpoint should follow redirects. WEWe should respond with 302x status code and a `Location` header for the redirect target. We can also include the redirect page HTML in the body Note that there are different categories of the response - non-browser API clients will be able to read it.redirects that we may have to distinguish: For VisualEditor,== Wiki Redirects == Wiki redirects are defined explicity using the `#REDIRECT` syntax. Following these should be enabled per default, but can be disabled using `redirect=false`. index.php does this, and the RESTbase endpoitns do this. We can also include a representation of the redirect in the body of the response - non-browser API clients will be able to read it. Note that the representation may be in JSON, HTML, or JSON and HTML, depending on whether the request was made to `v1/page/{title}`, `v1/page/{title}/html` or `v1/page/{title}/with_html`. == Normalization Redirects == Normalization redirects happen when the Title requested isn't the canonical one. We should only serve content from the canonical title. Title normalization includes: * Converting the first letter to upper-case and converting spaces to underscores. * Normalizing unicode, resolving spurious HTML or URL encoding * Applying variant conversion The redirect itself should be permanent and cacheable. == Revision Redirects == We could always redirect from the `v1/page` endpoint to the `v1/revision` endpoint for the current revision (or the current flagged revision?). when we actuBut that really want to edit the redirect only makes sense for `v1/page itself,/{title}/html`. restbase supports `?redirect=false` query parameter.Would it be confusing if we don't do it for the metadata endpoing `v1/page/{title}`? Also, should the redirect be cacehable? Core should do the same.It will need purging...