Routes and Verbs

[Jezz Santos]

I am trying to establish a coding pattern (some rules) in the services we create for our business.

We are following the basic guidance laid out by apigree for designing RESTful services.

One of the rules we would like to adopt is to block certain route and verb combos that we don't want to support. Presumably we would send back a HttPStatusCode.NotSupported for these illegal combos, and perhaps a human readable message? 

The legal combos we do want to support are:

• GET /resource - lists all resources
  
• GET /resource/{id} - retrieves specific resource by ID
  
• POST /resource - adds a new resource 
  
• PUT /resource/{id} - updates specific resource by ID
  
• DELETE /resource/{id} - deletes specific resource by ID
  

There are some illegal combos we explicitly don't want to support.

• POST /resource
  
• PUT /resource
  
• DELETE /resource
  

We do have validators for each of the supported routes.

But we don't have any of these illegal routes defined anywhere in our codebase.

From testing we have learned that if a client sends a GET /resource/{id} request with a blank id (string.Empty), then ServiceStack magic does not execute the validator for that request (GET /resource/{id}), but instead redirects to GET /resource. We think it does the same for DELETE /resource/{id} and PUT /resource/{id}. But none of these 'default' behaviours is desirable, we would rather want to return a HttPStatusCode.NotSupported or with some header directing client to API documentation (or some such guidance).

Could you suggest some options to handle these cases explicitly in the framework?

cheers