Design an HTTP response for the UI

Problem

A directive can only handle success, validation, navigation, and swaps correctly when the server response has a deliberate contract.

Before you start

Choose whether the server or browser renders the result. Write down what the user should see after success, invalid input, expired authentication, conflict, and unexpected failure.

Choose the response

Use on-success or on-error for JSON. Use data-target and swap for HTML. Do not return HTML error pages to a JSON interaction or 200 for rejected form data merely to avoid the error path.

Failure path

Never expose stack traces, database errors, tokens, or internal identifiers in a public error body. Log a correlation ID on the server and return only that ID with a safe message.

Apply it now

Choose one endpoint used by a cookbook recipe. Write its method, URL, success status, success content type, failure statuses, and one real body for each path before changing the template.

Verify

Inspect every response in the Network panel. Confirm its status and content type match the body, an empty success is actually empty, and each failure reaches the intended UI path.