Is the ActivityPub API a complete replacement for existing service APIs?

[evanp]

One question here is whether it's a goal to have the ActivityPub API be a complete replacement for a server's existing API. It could also just be a compatibility layer that lets applications do some of their work with an API server, with more specialised work happening with per-server APIs.

My two guideposts for creating the pump.io API, on which the ActivityPub API is based, were AtomPub and Embedded Experiences. Neither one was a complete drop-in replacement for the server's full API; it wasn't really a goal.

Examples of per-server API functionality:

• Monitoring for server status (such as queue health)
• Administrative tasks (approving new users, changing server settings)

These could be modeled as activities, but maybe it's not a good goal.

[ThisIsMissEm]

Usually those things would be out-of-scope for a protocol. I don't think we'd ever create a full "replacement" for an application's APIs, and there'll likely always be a need for application specific aggregations and logic and features.

There's also features that change depending on your architecture. So like, whether you see servers that are more like the activitypub servers today, just with the C2S processing and a few more APIs for retrieving data, or whether you see servers that are more like a "personal data server" which is decoupled completely from applications.