Handle redirects

There are some situations were redirects are encouraged, specifically:

If two URIs differ only in the trailing slash, and the server has associated a resource with one of them, then the other URI MUST NOT correspond to another resource. Instead, the server MAY respond to requests for the latter URI with a 301 redirect to the former.

We could do this by throwing errors with 3xx status codes, but since these are not actual errors this is sort of wrong. On the other hand, this might be requested by functions that don’t actually return anything (e.g., setRepresentation), so they have no real way of returning anything in another way.

Related to #11 and #86 .

[joachimvh]

This comment pertains specifically to

If two URIs differ only in the trailing slash, and the server has associated a resource with one of them, then the other URI MUST NOT correspond to another resource. Instead, the server MAY respond to requests for the latter URI with a 301 redirect to the former.

Assuming we probably do want to do the redirect.

If we don’t want to change the interface of ResourceStore, I can only see a few possible ways to go about this:

• Have the GetOperationHandler (Head/Post/Put/etc.) handle this. It could do an additional request to the store with a differing trailing slash if the first request resulted in a 404. This would increase the amount of requests that is done in case of every 404 though.
• In the case of GET (and HEAD), we could have the store always return the result independent of trailing slash, and then have the operation handler check if the input identifier matches the resource identifier. If not a redirect can be done.
• As mentioned in the initial comment, they could be handled the same as errors, even though they’re not. This would also require an extra field in the “error” object to contain the redirect URL.
• The ResourceStore adds a field to the RepresentationMetadata indicating the status code that should be used (but also only works for GET/HEAD since only there metadata gets returned).

If we do change the interface of ResourceStore, some solutions include

• Having all functions return a “Status” object next to their other return value that corresponds to the response status code (similarly to how we handle errors now). Potentially those objects then contain a function that can add headers to a server response (e.g., link headers for 201 and 301).
• Add a function that returns a boolean if a resource exists in the store or not (or only returns the metadata). This would decrease the cost in case we let the operation handlers do multiple requests to check if a redirect exists.

Note that it is recommended to only return 301 for GET/HEAD (and 308 for POST) so there is something to be said for the solutions that would only work with GET/HEAD.

[joachimvh]

Added in #1064