HTTP 200 is only the beginning

01 / What was actually completed

An agent sends an article to a content management system, or CMS. It receives a 200 response and reports success. The editor opens the page: the title is new, but the episode relationship is still old. Or everything looks correct in the dashboard while readers see the previous version. These are different problems that a status code alone cannot settle.

Under RFC 9110, section 15.3.1, 200 indicates that the request succeeded; response content depends on the method. This means more than merely “the connection works”. However, a faulty application can implement or describe an operation incorrectly. Business acceptance needs evidence that the expected state was reached.

Ask four separate questions: does the response indicate success, were the values persisted, did other data remain correct, and does the target view show the right material? This resource adapts a method from a historical integration audit. It is not a current defect report for any website.

02 / Define the expected state first

Before writing, preserve the object's state and list the intended changes. In our fictional example, the article has identifier demo-article-1, status draft, title “Version A”, two categories and a relationship to demo-episode-1. We want the title to become “Version B” and the relationship to become demo-episode-2. Status, identifier and categories must remain unchanged.

{
  "change": {"title": "Version B", "episode_id": "demo-episode-2"},
  "preserve": {"id": "demo-article-1", "status": "draft", "categories": ["science", "workshop"]}
}

This is a teaching model, not a ready-to-send WordPress request. The WordPress REST API posts reference defines separate retrieval and update operations and typed fields. Custom fields need their own contract. Do not copy invented field names or string identifiers from this exercise into a production API.

For every field, establish what omission, an empty list, an empty string and null mean. Do not assume that all mean “leave unchanged”. Check that you are writing your own draft and that the account is authorised for the operation. Test on a clearly labelled technical object, not on a published editorial article.

03 / Readback must be a separate step

A write response may merely echo submitted values. Do not compare the submitted title only with that request's response. Retrieve the object again, check its type and identifier, then compare persisted values against the expected state.

Check fields you did not intend to change too. If the title and episode are correct but a category disappeared, the write has not passed acceptance. “Partially completed” is more honest than a green “done”. Do not hide a mismatch by displaying a local copy of what you intended to send.

A response schema does not prove that writing works. The WordPress REST API extension documentation distinguishes a field's schema, retrieval and update callback. An installation can have additional rules and permissions; test them instead of attributing a plugin's behaviour to all of WordPress.

04 / Run five local trials

Download the Python demonstration. The script uses only the standard library, writes a temporary JSON file and reads it separately after writing. It has no network connection, needs no account or key, and does not start a CMS. Its temporary directory is removed when the run ends. The http_status field is a fictional value in an object, not the result of a real HTTP exchange.

python cms-readback-demo.py

Five trials were run on 25 September 2026. All tests passed: the demonstration checker accepted the correct case and detected four deliberately introduced problems:

• Correct write: new title and episode, preserved identifier, status and categories — accepted.
• Ignored field: the response acknowledges the request but the persisted episode remains old — an episode_id mismatch is detected.
• Collateral change: new fields are saved but categories become a different list — an unintended change is detected.
• Error inside 200: the response body has an error field despite its 200 status — not accepted as success.
• Wrong object: readback contains the correct new values but a different identifier — rejected.

This is an actual run of a teaching model, not a measurement of WordPress reliability. The script does not test authentication, networking, caching, concurrency or rendering. It should not be used directly as a production client. Validate error fields and response structure against the real integration's contract.

05 / Retry reads, not object multiplication

If a read returns an old value, bounded read retries may establish whether the state is still updating. Record the attempt count and time limit. A persistent mismatch remains an error to investigate; do not conceal it through endless waiting.

A write timeout can mean that the response was lost even though the object was created. Before creating again, locate the outcome using a durable operation identifier or use idempotency if the system actually supports it. Do not invent a header and assume the server will honour it. When an operation's effect is unknown, stop further writes and establish the state.

Reading before updating does not by itself resolve a race with another editor. If someone changed the object after your read, resending the entire old copy can undo their work. A version check or conditional update supported by the API is needed. Without that mechanism, limit the scope of the change and agree how conflicts will be handled. Automatically restoring an old state is not always a safe repair.

06 / The dashboard and public page need separate checks

A correct CMS record does not guarantee the correct view. The page may use another field, stale cache or an incorrect address. After authorised publication, check the target URL and content, not only its 200 status. A login page or error message can also arrive in a successful HTTP response.

Review the title, lead, body, captions, illustration, alternative text and relationships. For a player, test actual playback of the correct material, not just the presence of a frame. A native CMS component need not use an iframe; the test should check function rather than one chosen HTML structure.

Keep the dashboard address, public address and canonical reference distinct. Confirm that they identify the right material. Check social-card metadata and structured data if they are in the agreed scope. Do not invent information just to satisfy a validator's field count. Review appearance and operation on wide and narrow screens. Draft preview does not replace a separate post-publication page check.

07 / Integration completion checklist

• Target and authority: correct environment, object, status and action scope; publication distinct from saving a draft.
• Contract: types, required fields, omissions and clearing behaviour tested on an owned test object.
• Write: a response valid under the contract, without a hidden application error.
• Readback: object identity and every changed field confirmed through a separate operation.
• Side effects: preserved fields and relationships, version conflict handled, no unintended duplicate.
• View: target material, media, addresses and agreed metadata checked in a browser.
• Evidence: time, client version, operation identifier, expected and retrieved state, and mismatch list; no secrets in the log.
• Closure: technical object deleted or trashed according to the plan and its final state checked. Do not delete an object whose ownership is unclear.

Acceptance of one operation does not certify the whole integration. Draft creation, update, media assignment and publication are separate cases. Permission to use an image does not imply authority to change its metadata across all articles. Keep separate identifiers for the article, series, episode and externally hosted recording.

08 / Sources and limits of the evidence

The full internal integration report dated 15 September 2026 was read. This edition uses its method: pre-change state, separate readback, distinction between a declaration and a test, and final-view verification. Private accounts, dashboard addresses, identifiers and a particular site's defect catalogue are excluded from the public example. That site's current production environment was not retested.

The HTTP and WordPress documentation linked above was checked on 25 September 2026. It explains mechanisms; it does not prove that an installation's custom fields work. The local test covers the five described cases in a fictional JSON store. A real CMS needs separate acceptance on controlled objects.

Codex prepared the PL/EN text, diagram and demonstration code. Author review was completed without an independent second-model review. AI involvement is explicit; a human can withdraw this edition after publication. Contract changes, demonstration errors or material documentation changes trigger correction.