The database row that keeps a printed QR code useful

Print once, update the destination

Once a QR code is printed, replacing it is inconvenient. I approached VisionLink QR around that constraint: the code can point at a managed reference, while its destination can change behind the scenes.

Changing the pointer, not the print

The update endpoint reads link, new_redirect_to and name. It extracts the reference ID from the link, builds a partial update object and updates qr_reference once. The stored redirect_to is the moving part; the reference encoded in the printed code can remain the same.

The handler returns early if there are no supported fields to change. In this version, the truthy checks also mean an empty string is not treated as an instruction to clear a value. That is an API behaviour worth knowing about when building the edit form.

The small endpoint still deserves hard questions

The inspected handler is concise, but concise is not a security guarantee. Request validation, destination policies and ownership enforcement are separate questions to verify across the endpoint and database policies. I would rather discuss those boundaries than imply that a working update button proves the whole service is hardened.

Indirection is the useful feature

The interface can stay small because the benefit is specific. Create a code, download it, then manage the destination without treating each change as a new print job.

The engineering takeaway

A tiny public interaction can need a proper management workflow behind it. The separation between a stable reference and an editable destination is the core of this project.