A database image HTTP endpoint should return encoded image bytes with the correct media type. Keep each request's record identifier, query result and response context together, then check browser addressing, caching and late responses so each display shows the intended image.
Serve the selected database image as the body of an HTTP response, with a matching image media type. The display client needs a reachable URL that returns those bytes, not merely a database query that succeeds. Keep the requested record identifier attached to its query result and response throughout processing. That separation matters when several screens request different work orders at the same time: removing a shared image file does not remove every source of shared state.
What the endpoint does
A database image HTTP endpoint turns a request for a record into an image response. For example, a browser might request /work-orders/WO-123/image. The server checks access, validates the identifier, queries the database, extracts the image and returns it to that browser.
The image does not have to become a permanent file on the web server. The server can return bytes directly from the query result. This avoids repeatedly overwriting a file such as current-image.png, whose contents could change between selection and display.
A preview inside a database tool or development dashboard proves only that that tool can interpret the data. Another browser component needs its own supported image source. It cannot inherit the preview or access an internal flow variable.
This is a browser-facing application task. The distinction between a live factory data display and a signage playlist helps establish whether your display needs this request path at all.
Trace the record through every boundary
Check the full path before changing the display layout. At each boundary, establish both what the data contains and which request it belongs to.
| Boundary | What should be present | What a mismatch suggests |
|---|---|---|
| Browser request | The intended record identifier and access credentials | Wrong URL construction or missing authentication |
| Query input | A validated identifier supplied as a query parameter | Incorrect mapping or unsafe query construction |
| Query result | The expected record and its image field | Wrong filter, ambiguous join or missing image |
| Image conversion | Encoded image bytes in a supported format | Confusion between binary data, text and raw pixels |
| HTTP response | Correct status, media type and image body | Response assembly or request-routing fault |
| Display client | The intended URL and the latest selected record | Addressing, caching or asynchronous update fault |
During diagnosis, log a request correlation identifier, the requested record, the returned record, the status and the image byte length. Avoid logging image bodies, credentials or sensitive production data.
Where the query can return several rows, define which row is valid. Silently taking the first row can conceal a query problem. If a work order maps to several parts, the application needs an explicit image-selection rule rather than an accidental database ordering.
Return an image, not its database wrapper
A database field may contain a complete encoded image, base64 text, a file reference or application-specific binary data. Those representations need different handling.
If the field contains complete PNG or JPEG bytes, the endpoint can return those bytes directly. If it contains base64 text, decode the text into bytes before returning a normal binary image response. If it contains raw pixels, an image encoder must first create a browser-supported image file.
Do not convert binary bytes to an ordinary text string. Do not return a JSON object containing the image field and expect an image element to extract it. JSON is appropriate for a metadata API, but an image URL should normally return the image itself.
For a successful PNG response, the body is PNG data and the Content-Type is image/png. A JPEG response uses image/jpeg. The declared type must match the actual encoding. Assigning an image media type to arbitrary binary data does not convert it.
Check the returned bytes against the expected format, and apply limits to image size and dimensions. Unexpectedly large images can consume server memory and delay a small display even when the database lookup is quick.
Keep each request separate
Each request needs its own identifier, query parameters, result and response destination. An asynchronous query must complete the response that initiated it, not whichever response object was stored most recently.
In a flow-based application, preserve the original request context through the database and conversion stages. Some processing components replace the message with query results. If that happens, carry the request context forward using the runtime's documented mechanism rather than placing it in a shared variable.
Avoid application-wide variables such as selectedWorkOrder or currentImage for request-specific data. Consider two overlapping requests:
- Request A asks for one work order and begins a slow query.
- Request B asks for a different work order and finishes first.
- Request A then finishes.
Both responses must still contain their own requested image. The order in which queries finish must not determine which image a response receives.
A cache is not inherently unsafe, but its key must include everything that changes the result. That may include the record identifier, image revision and access scope. A single cache entry called latest-image recreates the shared-file problem in memory.
Make the URL reachable from the display
The browser fetches the image from its own network location. An address that works on the application server may not work on the display.
In particular, localhost refers to the device making the request. In a browser running on a separate display, it refers to that display, not the database server or application host. Use a server address that the actual client can reach and resolve.
Also check the page's security context. An HTTPS page can block an HTTP image as mixed content. Browser content security policy can restrict permitted image sources. Cross-origin image display and script-based image retrieval do not have identical requirements: a script fetch or canvas operation may need cross-origin permissions that a simple image element does not.
Authentication must suit the client component. A basic image element cannot attach an arbitrary authorization header in the same way application code can. Use a documented, access-controlled delivery method rather than exposing the database or embedding database credentials in the page.
The broader requirements for a web page signage player are separate from whether this endpoint returns a valid image. Verify both before choosing a display application.
Control caching and late responses
A correct endpoint can still appear to show the wrong image when the browser reuses a cached response or applies an older request after a newer selection.
Use record-specific URLs rather than one mutable URL for every selection. If an image can change without its record identifier changing, define a revision or validation strategy. A versioned URL can identify a particular image revision. Conditional requests can use an ETag when the server implements it correctly.
For sensitive responses that should not be stored, consider Cache-Control: no-store. Where browser caching is appropriate but shared caching is not, use a suitable private cache policy. Choose this deliberately rather than relying on browser defaults.
On the client, capture the selected record when starting the request. Before applying the result, confirm that the same record is still selected. Cancel obsolete requests where supported, but keep the selection check: cancellation alone is not a complete correctness rule.
Display the record identifier beside the image. This gives you a visible way to catch a mismatch between the selection, caption and picture.
Make missing and failed results explicit
A valid image response normally has a success status and an image body. A missing image should follow a defined application policy, such as a not-found response that the client handles with a clear message. A query failure should not return a success status containing an HTML error page disguised as an image.
Set bounded database and request timeouts. Ensure each request reaches one response path, including conversion errors and missing results. Do not leave the browser waiting indefinitely or attempt to send a second response after the first has completed.
If loading fails, avoid leaving the previous work order's image visible without a warning. Clear it or label it explicitly as the previous image. For production instructions, a stale picture paired with a new record label can be more misleading than a blank image area.
Keep image delivery separate from machine control and safety functions. An illustration endpoint is not a substitute for the controls or approved instructions required by the process.
Check the endpoint and client independently
Start with a known record and inspect the response in the browser's network tools. Confirm the requested URL, status, media type and returned image. Opening the endpoint directly helps separate server-side delivery faults from layout or component faults.
Then check overlapping requests for different records. Deliberately include a slower response, a missing image and an expired session. Confirm that each response remains associated with its request and that an old response cannot replace a newer selection.
Finally, repeat the checks from the actual display location. Network reachability, authentication and browser policy may differ from the development machine. If the endpoint returns the right image there but the embedded view fails, investigate the client component. If the endpoint returns the wrong record or malformed bytes, correct that path before changing the screen layout.
Questions
Does a database image need to be saved as a file first?
No. An endpoint can return encoded image bytes directly from a database query. A permanent file is optional. Avoid using one shared file for every selection, because overlapping requests can overwrite its contents before another client has retrieved the intended image.
Why does an image appear in a database preview but not in a browser?
The database tool may decode the field or construct its own preview. The browser needs a reachable URL whose response contains a supported image encoding and a matching media type. A JSON wrapper, base64 text or raw pixel data is not automatically a normal image response.
Can several displays request different database images at once?
Yes, if the application keeps each request's identifier, query result and response context separate. Shared selection variables, shared response objects and incorrectly keyed caches can still mix records. Check overlapping requests with deliberately different completion times before deployment.
Why does the wrong image appear after changing records quickly?
Check shared server state, cache keys and the client's handling of late responses. An older query can finish after a newer selection. Before displaying a result, the client should confirm that the response still belongs to the selected record and keep the visible label matched to the image.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.