Skip to content

wp-rest-api: resource endpoint completeness, internals reference - #4

Open
sboisvert wants to merge 2 commits into
trunkfrom
principal-wp/wp-rest-api-improvements
Open

wp-rest-api: resource endpoint completeness, internals reference#4
sboisvert wants to merge 2 commits into
trunkfrom
principal-wp/wp-rest-api-improvements

Conversation

@sboisvert

Copy link
Copy Markdown

Summary

Adds references/rest-api-internals.md and a SKILL.md procedure note on resource endpoint completeness.

references/rest-api-internals.md

Covers non-obvious behaviors:

  • Parameter resolution priority (URL > body > query)
  • Batch operations
  • The authentication filter
  • Pagination limits
  • Canonical error format

SKILL.md update

New step "Resource endpoint completeness": when building a REST API for a resource, consumers (mobile apps, SPAs, third-party integrations) typically expect both:

  • a collection endpoint (GET /resources), and
  • a single-item endpoint (GET /resources/{id}).

If omitting the single-item endpoint, document the rationale as a design decision — in practice it is almost always needed.

Why this is useful

This is a recurring shape error. A team builds the collection endpoint they need for their own UI, ships the API, then has to retrofit single-item endpoints when an external integration arrives.

Test plan

  • Confirm references/rest-api-internals.md renders correctly
  • Confirm SKILL.md "Deep reference" pointer resolves to the new file

🤖 Generated with Claude Code

Adds references/rest-api-internals.md covering parameter resolution priority,
batch operations, the authentication filter, pagination limits, and the
canonical error format.

SKILL.md: new step "Resource endpoint completeness" — when building a REST
API for a resource, consumers (mobile apps, SPAs, third-party integrations)
typically expect both a collection endpoint and a single-item endpoint. If
omitting the single-item endpoint, document the rationale as a design
decision; it is almost always needed.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@sboisvert
sboisvert force-pushed the principal-wp/wp-rest-api-improvements branch from 6bb54c3 to 960f21a Compare May 6, 2026 23:39
New references/recent-release-deltas.md covering REST-specific changes:

Real deltas:
- New top-level namespace wp-abilities/v1 (6.9)
- register_post_type embeddable arg (6.8) -- decouples embed from public
- rest_menu_read_access filter (6.8) -- public menu exposure
- wp/v2/templates source can be 'plugin' (6.7) -- new value for headless
- register_post_meta label arg (6.7)
- Notes reuse wp/v2/comments comment_type=note, excluded by default (6.9) --
  silent data loss for comment-mirror integrations
- rest_preload_api_request trailing-slash fix (6.8)

Important non-deltas explicitly called out:
- No autosaves/revisions controller changes 6.7-6.9
- No font collections/families/faces controller changes
- Block bindings sources deliberately NOT exposed via REST
- Streaming block parser is PHP-only (no REST wrapper)

Plus production gotchas worth re-emphasizing:
- WP_Error vs false for 401/403 in permission_callback
- register_rest_field N+1 hazard + cache priming patterns
- register_meta with show_in_rest needs full schema for object/array
- _embed scoping vs N+1 (Trac #46249)
- Batch endpoint 25-item cap, no GET, require-all-validate semantics
- Application Passwords are long-lived and inherit full caps
- Multisite per-site namespace + switch_to_blog discipline
- rest_pre_dispatch ETag/If-None-Match pattern
- VIP 60s default REST TTL + wpcom_vip_rest_read_response_ttl

Sources: 6.7/6.8/6.9 Field Guides, individual dev notes, Trac, VIP docs.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant