Resource management scenarios

The resource management scenarios discussed in this document have been separated based on the type of issue being faced:

• Removing a resource
• Moving a resource
• Aliasing a resource
• Processing form submissions
• Handling errors
• Other resource management issues (using best fit statuses)

Each section contains a decision tree to aid the selection of the appropriate HTTP status and message for different resource management situations.

Removing a resource

When a resource has been removed or deleted (permanently unavailable) or it is only temporarily unavailable, it is important to avoid presenting the user with the File not found (404) status.

In a perfectly maintained architecture the File not found (404) status would only be required when the user enters an URL that never existed (example: due to an input error, or a failed URL guess), and even then, you may be able to provide a more helpful response (see Handling errors section for more discussion).

Moving a resource

HTTP redirection is useful as a fallback measure for when a URL can no longer be persisted because the resource has been relocated.

Aliasing a resource

It can sometimes be useful to provide more than one URL that references the same resource, this is referred to as URL aliasing. It is important to remember that for every resource there should be only one canonical URL, any aliases for the same resource should redirect to the canonical URL.

Processing form submissions

Best practice for handling form submissions dictate that:

• The user should be able to return to the page containing the form they submitted using only a single click of their browser software's back button.
  • When a user is returned to the form page, the form should still contain the data the user submitted (modern user-agents provide this behaviour by default).
• If the action is 'safe', the resultant page should be directly addressable (so the result page's URL can be emailed or bookmarked).

The following decision tree and the linked scenarios (including HTTP statuses and status messages) will help achieve these best practice requirements.

Handling errors

When not due to user error, these conditions largely represent a breakdown in the normal operation of a production server.

In the case of user error, the nature of the problem should be relayed to the user in as much detail as necessary for the user to understand what has happened and what they can do to fix the problem.

Sometimes a user input error condition can be predicted and an alternate course of action can be suggested. For example: if the user enters a common typographical error or misspelling, a link to the correct URL can be provided to the user (auto-correction of these typographical errors through redirection is not recommended, instead see RMS 4.9).

In the case of internal server errors, it is often useful to email or otherwise alert the site's administration team when they occur and inform the user that they have been notified.

The following decision tree is not exhaustive of all potential error conditions but should be considered a good summary of common error scenarios.

Using best fit statuses

It is important to use the most appropriate (best fit) status for each scenario. Once all previous decision trees have been considered, the following should also be considered before using 200, 302 or 404 statuses.