After the fix, each displayed value follows the intended tag path to the authorized controller source, bypasses stale HTTP cache entries, and reports its read status independently. Start at the screen: a frozen value, an unexpected value, or a partial display failure tells you which layer to test next.
What is the screen telling you?
Treat the display as the final consumer, not the source of truth. Record the shown value, its update behavior, and any quality or error indication. Then compare it with the value obtained through the API and the value visible at the controller-facing data source.
| Observation | Check next | Likely fault domain |
|---|---|---|
| Every value is old by the same interval | Repeat the HTTP request and inspect cache handling | Client, proxy, gateway, or server cache |
| One value is wrong while others update | Compare the requested tag path with the screen binding | Tag binding or path resolution |
| Authorized tags work but restricted tags fail | Inspect the caller identity and access decision | Tag-level authorization |
| Live values work but trends are slow | Inspect history query shape and response layout | Historian request or serialization |
| API and screen agree, but the controller differs | Trace the driver connection and controller source | Driver, controller route, or data-source mapping |
The first commissioning check is a three-point comparison: screen value, API value, and controller-facing value. If the screen differs only from the API, the tag may be right while the binding is wrong. If the API differs from the controller-facing source, continue at the API, driver, and path-resolution layers.
Should the live read use GET or POST?
Both designs can work, but they solve different request shapes. A GET request is suitable for one short tag path when the server and every intermediary apply explicit freshness controls. A POST request is the better bulk-read contract because it accepts a list in the request body without packing multiple paths into a URL.
| Setting | Location | Effect |
|---|---|---|
| Single tag path in query parameters |
GET endpoint |
Simple inspection and diagnostics, but exposed to URL-size, logging, and caching concerns |
| List of tag paths in request body |
POST endpoint |
Handles bulk reads and preserves the submitted list as one synchronous operation |
| Freshness policy | Server response and intermediary configuration | Prevents a prior live-read response from being presented as current data |
| Per-tag result status | Response contract | Separates a failed or denied tag from successful items in the same batch |
Do not place a body on GET for a multi-tag operation. Support across clients, gateways, and servers is unreliable. Select POST for the list endpoint, retain GET only if a single-tag diagnostic endpoint adds operational value, and apply the same access checks to both.
Check the contract by submitting one path and then several paths. The bulk operation must return one unambiguous result for every requested path without silently dropping duplicates, denied paths, or unresolved paths.
How do you prevent a live value from coming from cache?
GET responses can be cached, so an otherwise correct tag request can repeatedly deliver an older representation. The operator sees a valid-looking number that no longer follows the controller. Changing the HTTP verb alone does not diagnose browser-side application caches or server-side memoization.
- Issue the same read twice while deliberately changing the source value between requests.
- Inspect whether the second request reaches the API service and whether the service performs another tag read.
- Review the response freshness controls and the behavior of every reverse proxy or gateway on the route.
- Check the client for retained responses, polling code that reuses a completed result, and updates blocked by an unchanged binding.
- Repeat the test with a unique request correlation value used only for tracing, not as a substitute for correct cache policy.
For live reads, configure responses so shared and private caches do not reuse them. Apply that policy to both the single-tag and bulk-read endpoints. A POST bulk API is preferred for request shape; an explicit cache policy remains the control for freshness.
The proving check is a controlled source change followed by two independent clients reading the new value. Confirm that both requests reached the service and that neither client displayed the previous response.
How does each requested path reach the correct controller value?
A web request does not read a screen object. It submits a tag path that the API resolves against its configured namespace, after which a driver or equivalent data provider obtains the controller value. The returned item must preserve the relationship between the submitted path and the resolved result.
- Copy the exact path used by the API request and compare it with the path bound to the screen object.
- Resolve that path through the same namespace and data provider used by the API service.
- Confirm that the provider points to the intended driver connection and controller source.
- Read the value at the provider layer, then compare its value and status with the API result.
- Correct the screen binding when the API result is right but the displayed object references another path.
Bulk processing must not turn one path-resolution failure into a failed batch. Return a result for each input item, retaining request order or providing another deterministic association. Distinguish a missing path, a denied path, a communication failure, and a valid value; an empty value cannot represent all four states.
Check one valid path, one unresolved path, and one path whose access is denied. The response must associate each outcome with the correct request item, while the valid path still updates.
Where should tag access restrictions be enforced?
Enforce authorization inside the API service before reading or returning each tag. Network reachability and successful authentication identify a caller; they do not grant access to every tag in the namespace. Filtering only in the screen leaves the API capable of exposing data directly.
| Control | Location | Effect |
|---|---|---|
| Caller authentication | API entry point | Establishes the identity used for subsequent decisions |
| Tag-path authorization | Before each live or history read | Limits which paths that identity may query |
| Per-item denial result | Bulk response | Reports restricted items without disclosing their values |
| Request audit record | Service logging layer | Correlates caller, requested operation, and outcome without logging returned process values unnecessarily |
Apply identical authorization logic to GET, POST, and history methods. Otherwise, a caller blocked from a live endpoint may retrieve the same tag through history or an alternate route.
Check with two test identities that have different permitted tag sets. Each identity must receive values only for its allowed paths, and a mixed bulk request must not leak restricted values through error text, metadata, or cached responses.
How should history and end-to-end verification work?
Keep history separate from the synchronous live-read operation because it has different inputs, volume, and response semantics. Authorize every requested path before querying history. For efficient transfer, serialize history column-wise: send aligned collections for time, value, and status rather than repeating those field names in every row.
Column-wise data depends on positional alignment. Entry five in each collection must describe the same sample. Define how the response represents missing samples and mixed data types, and reject malformed requests before starting a large query. The client must validate collection lengths before plotting a trend.
- Change a selected controller value to a recognizable test value through the approved commissioning method.
- Confirm the driver-facing source reports that value with a successful status.
- Submit a live bulk request containing the selected path, another valid path, an unresolved path, and a restricted path.
- Verify that the API returns the changed value, preserves item association, and reports the other outcomes independently.
- Confirm the screen object bound to the selected path displays the changed value rather than a cached response.
- Query the permitted path through the history method and verify that all returned columns have matching lengths and aligned samples.
The final commissioning record should capture the screen value, requested path, API result, access outcome, driver-facing value, and controller-facing value from the same test transition.
FAQ
How do I read multiple tags through a web API?
Use a POST operation that accepts a list of tag paths in its request body. Return one associated status and value result per requested path so a missing or denied tag does not invalidate successful reads.
How do I stop a GET tag read from showing stale data?
Configure the live-read response and every intermediary to prevent reuse, then change the source value between two requests. Verify that the second request reaches the service, performs another tag read, and updates the screen.
How do I verify that the screen uses the correct tag?
Compare the screen binding with the submitted tag path, resolve it through the API namespace, and trace it through the driver to the controller-facing source. Finish by changing the source value and confirming the driver, API response, and screen all report the same new value.