How should API endpoints correspond to product features?

How should API endpoints correspond to product features?

API endpoints should support the actions users need to perform while expressing clear domain concepts. Begin with the approved feature list and user journeys, then define operations that deliver those behaviors without exposing unrestricted access to database internals.

Map actions to resources

An event-management feature may need operations to create an event, list a wedding's events, edit one, and archive it. A task feature may need separate operations to assign work and update its status.

Use consistent paths and methods, such as reading events with GET /api/weddings/{weddingId}/events and creating one with POST to that collection. These examples are a starting convention; the contract must still define payloads, permissions, and results.

Represent distinct workflows explicitly

Invitations and RSVP responses deserve their own contracts because they have different actors and rules. An organizer sending invitations is not performing the same operation as a guest submitting attendance choices.

Avoid forcing every action into a generic update endpoint that accepts any field. Explicitly define which fields each actor can change and which transitions are valid. This makes it harder for a client to alter internal state accidentally.

Check coverage and practical usage

Create a simple mapping from each required screen action to its API operation. Confirm that loading, saving, filtering, and error recovery are possible with the proposed contract.

One screen may use several endpoints, and one endpoint may support several screens. The mapping does not need to be one-to-one. Ask AI to identify uncovered actions and redundant operations, then review its suggestions against real workflows. Include server-side wedding membership checks and record ownership validation wherever an operation touches protected data.