We currently have /, /debug/, /sandbox/username/ and /debug/sandbox/username/ endpoints for convenience, because having debug and sandbox as query string parameters would require passing the target URL as a query string parameter as well (because target URLs may include query strings and URL fragments themselves), and this would require URL-encoding the target URL, which would be impractical for users simply prepending the server's address before their target URLs.

However, for internal or advanced use (such as the use we would give to this JSON endpoint) we may have a single /translate endpoint (we may have a /test endpoint for T302724), accepting parameters such as:

• format:
  • html: the standard HTML + embedded metadata output returned by our shorthand endpoints above
  • json (or mediawiki, mimicking Citiod API): the JSON output referred to in this task
• debug: boolean, whether present or not; output debugging information (can we fit this into the JSON output?)
• storage: where to get configuration files from; defaults to https://meta.wikimedia.org/Web2Cit/data/. More general-use than our sandbox endpoints above.
• citoid: as described in T306133, we may use this to tell the server to always include the citation returned by Citoid along with the Web2Cit citation.
• test: whether tests (expected outputs and test scores) should be included along translation outputs. Supported by both formats (mediawiki/json and html).
• other parameters use to configure the Domain object.

Make sure that the configuration switcher (main vs sandbox) in the html results page is compatible with urls using the translate endpoint.

Likewise, consider removing the need to pass debugHref and nodebugHref parameters to the HTML renderer.

For both cases we may use the translate endpoint, and have this endpoint decide whether to redirect to one of our shorthand endpoints.