ServiceStack Route design

问题:

Are these 3 routes the same? Which one is normally preferred?

[Route("/todo/{id}", "DELETE")]
[Route("/todo/delete","POST")]
[Route("/todo/delete/{id}","GET")]
public class DeleteTodo : IReturnVoid
{
    public int Id { get; set; }
}

Thank you very much...

回答1:

The preferred route is actually to include the Id in the pathinfo since DELETE requests don't have a HTTP Request Body you can submit this info on, e.g:

[Route("/todo/{id}", "DELETE")]
public class DeleteTodo : IReturnVoid
{
    public int Id { get; set; }
}

For pragmatic reasons you may want to allow a POST to do the DELETE since browsers my default (and some proxies) don't allow sending of DELETE Requests.

[Route("/todo/{id}/delete", "POST")]
public class DeleteTodo : IReturnVoid
{
    public int Id { get; set; }
}

You can simulate a DELETE request in Ajax or jQuery by adding the X-Http-Method-Override HTTP Request header in your Ajax call or as a field in your FormData or QueryString, e.g.

POST /todo/1
X-Http-Method-Override=DELETE 

or embedded in the HTML FormData like:

<form action="/todo/1" method="POST">
   <input type="hidden" name="X-Http-Method-Override" value="DELETE"/>
</form>

Though it's important not to allow DELETE's via GET as by contract GET's should have no side-effects so are safe to be cached and replayed by HTTP middle-ware like proxies, etc.

回答2:

If you want to follow REST guidelines, you should not use GET or POST to delete a resource.

The GET verb is used to read a resource. An important rule of thumb is that a GET operation is safe. That is, it can be done repeatedly without changing visibly the state of the resource. This property is very important for various reasons. First, indexing engines use GET to index the contents of a resource. So it would be bad if indexing a resource also changed it. Second, intermediaries, such as proxies, may cache results of a GET operation to accelerate subsequent accesses to the same resource.

The PUT and DELETE verbs allow a request to alter the state of a resource atomically.

The POST verb can carry a variety of meanings. It's the Swiss Army Knife of HTTP verbs. For some resources, it may be used to alter the internal state. For others, its behavior may be that of a remote procedure call.

Have a look at that page for a complete description.