Yes — registering the post type with show_in_rest => true gives it a full wp/v2-style route automatically, with the same field-extension tools (register_rest_field, meta REST visibility) available on top of it.

Yes, and it should be explicit — __return_true is a valid permission callback that documents the route is intentionally open, rather than an oversight the next developer has to investigate.

It depends on how the field was registered — meta fields need an explicit auth_callback if their visibility should be restricted; without one, the default behavior may expose more than intended, so it’s worth checking rather than assuming.

Routes that operate on the same underlying resource — one controller per resource (projects, services, bookings), not one controller for the entire plugin’s API surface.

With a sensible default per_page and an enforced maximum that a request can’t override, so no single call can pull an unbounded result set regardless of what the client requests.

No — wp/v2 belongs to WordPress core, and core can add or change routes under it without warning. Always register custom routes under a namespace unique to the project.

A single custom endpoint that fetches data from one or more third-party APIs, combines it, and returns one unified response — common on enterprise projects that need to integrate several external systems behind a consistent internal API.

Context (view, edit, embed) controls which fields appear in which situations — a field meant only for the editor’s own use in the edit context shouldn’t also appear in the public view response an anonymous visitor can request.

It’s when a list endpoint runs one additional database query per item in the list to fetch related data, instead of one batched query for the whole list — invisible with ten items, a real bottleneck with a thousand.

The response shape can end up representing something that isn’t really a post, user, or term, forced into a schema that doesn’t naturally fit — at that point a purpose-built custom endpoint documents the data far more clearly.

Before other consumers depend on the route’s namespace and shape — a WordPress developer experienced with REST API architecture catches versioning and structure problems while they’re still a five-minute fix instead of a breaking migration.

Before a launch expecting meaningful traffic, and always before building an aggregation endpoint combining multiple third-party APIs — the failure and caching strategy is far cheaper to design up front than to retrofit after a production incident.

Early — before either direction is built out, since undoing an awkward wp/v2 extension or a redundant custom endpoint both cost more than making the right call up front.

For a single route with one or two methods and no shared validation logic. Once a resource needs multiple methods or the same checks repeated across callbacks, a controller class keeps that logic in one place.

When the data is a property of an existing resource — a post, user, or term — rather than a resource in its own right. If it doesn’t need its own create/read/update/delete lifecycle, extending the existing route is almost always simpler.

Because computing and formatting the response itself has a cost beyond the database query — caching the finished payload skips all of that work on repeat requests, which matters most for endpoints hit frequently by the same or similar queries.

Because the upstream APIs have different reliability, latency, and rate limits — caching and failing each one independently means a single slow or down integration degrades gracefully instead of taking down the entire response.

Because a breaking change to the response shape is inevitable eventually, and a versioned namespace (4wp/v1, 4wp/v2) lets the old and new shapes coexist during a migration instead of forcing every consumer to update at the exact same moment.