REST endpoints should themselves be Abilities

[justlevine]

Seems counterintuitive that we're creating traditional REST endpoints, when REST endpoints themselves are just shaped abilities.

Given that discovery is itself a conceptual Ability - and a useful one e.g. in the context of MCP Adapter and limiting tool numbers - I propose we dogfood our own APIs, and reimplement these endpoints as Abilities themselves that are just "adapted to" (i.e. wrapped in) \WP_REST_Controller.

Happy to create a POC if nobody beats me to it; IRL this should probably wait until after WordPress/ai#40 or be part of that spec.

[gziolo]

The repeating feedback I noticed so far is the opposite – how to also register an existing custom REST API endpoint as an ability or set of abilities. I'm noting that mostly to acknowledge the current reasoning of developers. I'm definitely in favor of exploring how we would build guidelines around when to avoid creating more custom REST API endpoints in favor of abilities. More importantly, for existing projects, there will be a need for a set of recommendations on how to turn them into abilities. I'm curious to see your POC to understand your current thinking on the topic better.

[justlevine]

The repeating feedback I noticed so far is the opposite – how to also register an existing custom REST API endpoint as an ability or set of abilities.

To clarify - I don't think these needs are exclusive. Users with existing REST endpoints who want the quickest migratory path to have them consumable as abilities shouldn't conflict with the long-term desire for the more robust "register once, consume anywhere" pattern of using the Ability as the source of truth for all last-mile adaptations.

Sent you a DM in the meantime but hopefully the POC will illustrate this better 🙇