A link labelled “delete” may look convenient in an administration screen. If following its URL sends a GET request that deletes a record, however, the interface has given a retrieval method a destructive meaning. That can turn ordinary link handling into an unintended action.
RFC 9110 defines GET as a safe method: its intended semantics are essentially read-only. “Safe” here describes what the client requests, not a claim that servers perform no incidental work such as logging.
Keep retrieval separate from the requested change
A GET route can display a record or a confirmation screen. The actual change should use an appropriate state-changing method and enforce the application’s authorisation and other security controls. Changing the method alone does not make an endpoint secure.
For example, a page can show the item selected for deletion and explain the consequences. A subsequent authorised request performs the deletion. The server must still verify that the user can act on that specific item; hiding the control in the interface is insufficient.
This matters because links may be fetched by crawlers, previews or other automated clients. An application should not depend on every visitor treating a URL as a carefully guarded command.
Do not confuse safe with idempotent
Idempotence concerns the intended effect of repeating a request. A method can be idempotent while still changing state. DELETE is a useful example: repeating a deletion can have the same intended end state, but deletion is not read-only. Therefore “it only happens once” does not justify putting it behind GET.
During an application review, inspect routes that contain action-like parameters and follow the request through the server logic. Test only authorised environments and use disposable records. Confirm that retrieval leaves business state unchanged, while state-changing requests enforce the required permissions.
A clear method boundary helps developers, clients and reviewers understand the interface. It also makes a confirmation screen meaningful: viewing the proposed action and carrying it out become two distinct operations.