locked
WCF Data Services 5.x still does not support PUT/DELETE extended operations? RRS feed

  • Question

  • Hi,

    We have a WCF Data Service built from our EF model and extended with a few operations. They are semantically deletion operations but we had to implement them using POST verb:

    [WebInvoke(Method = "POST")]
    public void DeleteSomething(string id) {...}

    This was due to the limitation of WCF Data Service 4.0 that only accepted POST method for service operations. I updated the service using latest ODataLib Nuget packages and hoped that it would accept DELETE. Nope: still "method not allowed".

    Such behavior is clearly not RESTful. Is there a chance to fix WCF Data Services so it will support all HTTP methods?


    Vagif Abilov

    Thursday, September 6, 2012 1:47 PM

Answers

  • Just to be clear, my understanding of your scenario is this:  You essentially want to override what DELETE means for one or more of your entities. The best workaround you came up with was to use a service operation, which is GET/POST only (and clearly POST is better of the 2). You want to know if service operations can now work with the delete verb.

    The simple answer to your question is "no". In 5.0, Service Operations are still GET+POST only. We don't have any plans to extend that at this point.

    We would love to allow you to totally rewrite what DELETE ~/MyEntitySet(1) means. That would be way more RESTful. We don't have anything in the books right now for doing that, however.

    You could look into a change interceptor. This would not stop us from generating a delete request to EF, but if your custom logic is strictly additive (IE, you do extra stuff on top of deleting the entity), it will be nicer than a service operation.

    Also, you could jump down a level to EF. EF allows you to map delete operations to stored procedures in the DB. You could do you custom logic there (is SQL) and then throw away your service operation and go back to the RESTful DELETE verb on your entity set.


    -Ian

    • Marked as answer by Vagif Abilov Friday, September 7, 2012 7:25 AM
    Thursday, September 6, 2012 10:14 PM

All replies

  • Just to be clear, my understanding of your scenario is this:  You essentially want to override what DELETE means for one or more of your entities. The best workaround you came up with was to use a service operation, which is GET/POST only (and clearly POST is better of the 2). You want to know if service operations can now work with the delete verb.

    The simple answer to your question is "no". In 5.0, Service Operations are still GET+POST only. We don't have any plans to extend that at this point.

    We would love to allow you to totally rewrite what DELETE ~/MyEntitySet(1) means. That would be way more RESTful. We don't have anything in the books right now for doing that, however.

    You could look into a change interceptor. This would not stop us from generating a delete request to EF, but if your custom logic is strictly additive (IE, you do extra stuff on top of deleting the entity), it will be nicer than a service operation.

    Also, you could jump down a level to EF. EF allows you to map delete operations to stored procedures in the DB. You could do you custom logic there (is SQL) and then throw away your service operation and go back to the RESTful DELETE verb on your entity set.


    -Ian

    • Marked as answer by Vagif Abilov Friday, September 7, 2012 7:25 AM
    Thursday, September 6, 2012 10:14 PM
  • Hi Ian,

    Yes, your understanding is correct: we are using EF but extend the corresponding OData service with additional service operations. They are not based on database stored procedures, so we can't map it throgh EF model.

    I remember once I tried to figure out why PUT/DELETE verbs were rejected and tried to dive into the code generated using Reflector. I got an impression that there were no serios reasons for not allowing these verbs - there was explicit check somewhere that service operation was using POST and everything else was rejected. This essentially makes service operations not RESTful, and I can't see why it shouldn't possible to lift this restriction.


    Vagif Abilov

    Friday, September 7, 2012 7:25 AM