A discussion started in T112956 that probably deserves it's own ticket.
Let's discuss how ORES could integrate into api.php and what that would look like.
**This task is done when:** We have a plan for which integration points will happen first (if any).
Here's some useful quotes from T112956
>>! In T112956#1909946, @Halfak wrote:
> Chiming in here because this question came up in discussions regarding the #ORES API. It seems that we are discussing this as either/or when I think we can have both since APIs can consume other APIs.
>
> As an API developer, I don't want to be constrained in that *everything* needs to operate behind either `api.php?` or `restbase_v1/` (so, +1 @nuria). This is because the API that we develop might not always make sense within the conventions of these spaces. I think it makes more sense that new API's adopt an appropriately flexible endpoint first and that we work on integration/bridges afterwards.
>
> E.g. ORES scores edits, so it fits well within `api.php?query=revisions` and `restbase_v1/pages/revisions`, but it also has endpoints that provide information about model fitness and other details that don't really make sense in these locations. `api.php` and `restbase_v1/` can consume the service just like any user and act as a bridge. In this case, we'd have both the flexibility to do new things with APIs *and* we can include the relevant outputs in `api.php?` and `restbase_v1/`. @anomie, at some point, I'd like to discuss with you what #ores integration in api.php would look like. I've already talked to @gwicke about what a bridge into `restbase_v1` will look like.
>
> The tradeoff of this strategy, of course, is that we'll have two ways to get at the same data. Honestly, I think that this is more desirable than the alternatives. If you want to get at the data through a familiar interface and are happy with the limitation imposed, use the extension to a standard API. If you need more or you want to work with something that's cutting edge and doesn't have a bridge/integration yet, learn how the flexible endpoint works.
>>! In T112956#1910793, @Anomie wrote:
>>>! In T112956#1909946, @Halfak wrote:
>> E.g. ORES scores edits, so it fits well within `api.php?query=revisions` and `restbase_v1/pages/revisions`, but it also has endpoints that provide information about model fitness and other details that don't really make sense in these locations.
>
> Model fitness and such could fit into the action API as a query meta module, if it's useful data.
>
>> @anomie, at some point, I'd like to discuss with you what #ores integration in api.php would look like.
>
> Yes, we should definitely do that.
>
>> The tradeoff of this strategy, of course, is that we'll have two ways to get at the same data. Honestly, I think that this is more desirable than the alternatives. If you want to get at the data through a familiar interface and are happy with the limitation imposed, use the extension to a standard API. If you need more or you want to work with something that's cutting edge and doesn't have a bridge/integration yet, learn how the flexible endpoint works.
>
> +1