Page MenuHomePhabricator

Reader follows a page redirect
Open, Needs TriagePublic

Description

"As a Reader, I want to know which pages are redirects and what they redirect to, so that I can go to the recommended page instead."

This is for endpoints that return a Page item in JSON format, such as /page/{title}, /page/{title}/bare, and /page/{title}/with_html. They should include these new properties:

  • is_redirect: is this page a redirect? boolean
  • redirect_title: if this page is a redirect, which page title it redirects to, in a readable human form
  • redirect_key: if this page is a redirect, which page title it redirects to, in a form good for plugging into API URLs

Related Objects

StatusSubtypeAssignedTask
InvalidNone
OpenNone

Event Timeline

I noticed this as I was working on the code for apiclient.wiki. It's hard to follow redirects.

Let's step back for a minute.

There could be 2 very distinct reasons for a redirect to happen:

Non-canonical titles

If the user used a non-canonical form of a title in the request. E.g. main Page instead of Main_Page. In this case, we can either simply return the data right away, or redirect the user to the canonical form. The former basically precludes us from using actively purged CDN caching for these endpoint - the possible URIs under which the content is cached in CDN become unpredictable. The latter create small performance impact on clients who use incorrect URI. I would think we should definitely 301 HTTP-redirect in this case.

Page redirects

The second one is for page redirects. I think by default we have to 302 HTTP redirect, with a possibility to include ?redirect=false query parameter for ALL endpoints. The main point here is that the default should better suite the most clients. Wikimedia sites are way more read-heavy then write heavy - thus the default should suite the readers better. HTTP redirects are automatic for the readers, thus preferable.

Additionally, we have the following benefits:

  • HTTP redirects will work for any content-type endpoint, not only for JSON, so we can have consistent way of dealing with redirects across all endpoints. We had a guiding principle about consistency I think. The solution proposed in the ticket covers only JSON. What are we going to do if non-JSON is redirected?
  • HTTP redirects are a w3c standard and REST is supposed to use as the capabilities of the HTTP protocol as much as possible.
  • We already are doing it in RESTBase and it works great. Works great with visual editor, works great for other clients, works great with CDN caching.
  • There's no performance impact, on the contrary, redirect responses can be cached in CDN cache for quite long
  • The 'redirect=false' flag could be optional for non-browser clients. If you want to, you can switch off automatic redirect following and you get the exact same experience as described in the ticket. Browsers can't switch off automatic redirect following, so if they do not want redirects, they just use ?redirect=false.