Would you like to submit a core patch?

Change 866734 had a related patch set uploaded (by Simon Stier; author: Simon Stier):

[mediawiki/core@master] make action 'raw' slot-aware

https://gerrit.wikimedia.org/r/866734

In T324910#8458712, @Tgr wrote:

Would you like to submit a core patch?

done. It's my first one, hope it doesn't need much rework.
Would there be an easy way for a backport to versions >= 1.35?

In T324910#8458783, @Simontaurus wrote:

Would there be an easy way for a backport to versions >= 1.35?

Yeah, once it's merged, use "cherry-pick" from the ellipsis menu on the top right.

Change 866734 merged by jenkins-bot:

[mediawiki/core@master] make action 'raw' slot-aware

https://gerrit.wikimedia.org/r/866734

Change 869350 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/core@master] Add action=raw&slot= to release notes

https://gerrit.wikimedia.org/r/869350

Change 868882 had a related patch set uploaded (by Gergő Tisza; author: Simon Stier):

[mediawiki/core@REL1_39] make action 'raw' slot-aware

https://gerrit.wikimedia.org/r/868882

Change 868883 had a related patch set uploaded (by Gergő Tisza; author: Simon Stier):

[mediawiki/core@REL1_38] make action 'raw' slot-aware

https://gerrit.wikimedia.org/r/868883

In T324910#8472134, @Tgr wrote:

In T324910#8458783, @Simontaurus wrote:

Would there be an easy way for a backport to versions >= 1.35?

Yeah, once it's merged, use "cherry-pick" from the ellipsis menu on the top right.

Looks like 1.35 needs a separate patch, the code was different then.

Please note that in T279120 and related tasks, I propose removing and reducing most index.phpaction=raw features down to only serving publicly accessible (i.e. not private namespaces, private wikis, revision-deleted) latest stable main slot revisions.

I realize this has just merged and we don't have a proper owner for this part of MediaWiki. I would suggest that for new functionality to use the Action API or REST API instead of building features on top of non-HTML responses through index.php, along with their mostly undefined cachability, performance, and hook/customizability contracts (e.g. how much should user preferences and UI-hooks influence the output). Also noting that it doesn't fall under any stable interface, API versioning, or deprecation policy, with no precedent for deprecating index.php parameters.

Was use of the Action API or REST API considered?
If so, what limitations did you run into?
If not, does the API currently have the to return the content of slots?
If not, could it be added there? Having this in our API seems like a more important primitive to provide.

\cc @daniel as working on REST APIs currently and having worked on MCR originally.

A REST API would definitely be superior for source access in the long term, especially if we can figure out how to disable session handling for certain endpoints (like we do for load.php) which would make issuing cache headers much safer. IMO as it is right now (without any support for self-documentation or a sandbox) the REST API is just not very usable in general. The action API already supports getting the content of specific slots, but has just as weird caching characteristics as action=raw.

In T324910#8483808, @Tgr wrote:

The action API already supports getting the content of specific slots, but has just as weird caching characteristics as action=raw.

If you prefer not to work on the new REST API at this time, could I ask to back this out in favour of the Action API? The Action API is an officially supported API with versioning and deprecation abilities, error handling, offers consumer opt-in for CDN caching on anon requests (smaxage), and (if you wanted to create a new endpoint) already provides support for general CDN caching without opt-in as well (as ApiOpenSearch and various others do).

It seems though that the relevant API already exists today. I don't know what upcoming feature or use case prompted this task, but that means it isn't blocked on a new API as it already exists.

Change 868882 merged by jenkins-bot:

[mediawiki/core@REL1_39] make action 'raw' slot-aware

https://gerrit.wikimedia.org/r/868882

Change 868883 merged by jenkins-bot:

[mediawiki/core@REL1_38] make action 'raw' slot-aware

https://gerrit.wikimedia.org/r/868883

In T324910#8484979, @Krinkle wrote:

It seems though that the relevant API already exists today. I don't know what upcoming feature or use case prompted this task, but that means it isn't blocked on a new API as it already exists.

As long as RawAction isn't deprecated (whatever that would mean for an action), it makes sense to aim for feature parity IMO.

In T324910#8483808, @Tgr wrote:

If you prefer not to work on the new REST API at this time, could I ask to back this out in favour of the Action API? The Action API is an officially supported API with versioning and deprecation abilities, error handling, offers consumer opt-in for CDN caching on anon requests (smaxage), and (if you wanted to create a new endpoint) already provides support for general CDN caching without opt-in as well (as ApiOpenSearch and various others do).

@Simontaurus would the action API work for your use case? An example of using it is https://commons.wikimedia.org/w/api.php?action=query&format=json&prop=revisions&titles=File%3A%CE%9F%CE%AF%CE%B1%201121.jpg&formatversion=2&rvprop=content&rvslots=mediainfo (sandbox). The content is wrapped in JSON (there is no way to get just the raw content string); other than that I don't think there's any disadvantage IMO. It supports batching, CORS, and can handle non-text-based content models; the caching characteristics are similarly unhelpful as action=raw but at least better defined.

(In general, the action API has full support for MCR AFAIK, with the exception of editing, which is generally not supported in core.)

In T324910#8485601, @Tgr wrote:

In T324910#8484979, @Krinkle wrote:

It seems though that the relevant API already exists today. I don't know what upcoming feature or use case prompted this task, but that means it isn't blocked on a new API as it already exists.

As long as RawAction isn't deprecated (whatever that would mean for an action), it makes sense to aim for feature parity IMO.

@Simontaurus would the action API work for your use case? [...] The content is wrapped in JSON (there is no way to get just the raw content string); other than that I don't think there's any disadvantage IMO. [...]

The usecase at this point is to place a machine readable document behind an URI. Specifically, it's about json-schema, which are referenced both absolutely and mutually among themselves.
(see also json-schema.org and T324933 )
In this way, for example, a category can specify the schema for structured data that must be followed by pages in that category.

This approach of course works best with MCR instead of subpages or page-twins in a different namespace.

To fetch json(-schema) data in slots I first tried to create a custom Action API module - but as you said, any content is wrapped in (additional) JSON by design. Since third party tools (like json-editor) in general are not aware of mediawiki specific return formats I sticked with action=raw and added the delivery of specific slots there - because it seems easier than patch every data consumer and it provides feature parity.

However, I absolutely agree that the REST API would be the best solution here, as it is standards compliant and, as I guess from SimpleHandler.php, does not wrap the return value. Are there any activities for providing read + write access via REST / would that be of general interest in the current state of development?

In T324910#8485601, @Tgr wrote:

(In general, the action API has full support for MCR AFAIK, with the exception of editing, which is generally not supported in core.)

Is there a specific reason that editing is not supported in core? Currently there is at least an extension for it

In T324910#8486070, @Simontaurus wrote:

To fetch json(-schema) data in slots I first tried to create a custom Action API module - but as you said, any content is wrapped in (additional) JSON by design. Since third party tools (like json-editor) in general are not aware of mediawiki specific return formats I sticked with action=raw and added the delivery of specific slots there - because it seems easier than patch every data consumer and it provides feature parity.

It seems like you'd have to provide a callback via the urn_resolver configuration parameter and make it unwrap the content. It doesn't seem complicated.

However, I absolutely agree that the REST API would be the best solution here, as it is standards compliant and, as I guess from SimpleHandler.php, does not wrap the return value. Are there any activities for providing read + write access via REST / would that be of general interest in the current state of development?

Read access looks pretty simple to add - see PageSourceHandler and RevisionSourceHandler and their bare option.
The edit endpoint is just a wrapper for the action API's edit module, which doesn't support slots. Creating a new editing endpoint which behaves differently from normal editing (to name one thing at random, doesn't integrate with AbuseFilter) is probably a bad idea.
The REST API does have a maintainer team. @BPirkle maybe you can advise on whether there would be any concern about a patch adding a slot option to the page/revision APIs, and if not, what would be the best approach (new route, new query parameter?).

In T324910#8485601, @Tgr wrote:

Is there a specific reason that editing is not supported in core? Currently there is at least an extension for it

The difficulty of getting resourcing for foundational work with high long-term strategic impact but no immediate user impact, I suppose? action=edit is a web form handler that pretends to be an API, and consists of about five thousand lines of highly convoluted code, so the amount of resources needed would have been substantial. The relevant task is T174033: Refactor EditPage to allow multiple slots to be edited atomically [MCR].

Change 869350 merged by jenkins-bot:

[mediawiki/core@master] Add action=raw&slot= to release notes

https://gerrit.wikimedia.org/r/869350