Hi all, Many years ago I had to debug a problem with a web server that used Delete to remove files on the server. The reason it failed was that a proxy server was rejecting the PUT and DELETE verbs.
Fast forward to six months ago, I was argued out of only using POST and GET on the service call, we implemented PUT, DELETE, POST and GET. One week ago, I find out that there is a bug raised where PUT is being refused from a client from a remote location and they can’t figure out why. As far as I am concerned PUT and DELETE were only ever part of the original RFC. They were never implemented correctly and should be treated with upmost distain when they are used. .02c Davy Sent from Mail for Windows 10 From: Tony Wright Sent: 27 March 2017 05:43 To: ozDotNet Subject: Re: WebApi - PUT and DELETE Well, we're well into development and have delivered a bunch of apps already, and it hasn't done anything to us so far. As long as we stick with the "use GET to retrieve data" and "use POST to modify data" basic rules, then I don't think we can come unstuck. In fact, this has to be acceptable because, if you read the pages and pages and pages and pages of arguments, you'll find some statements about PUT and DELETE being marked as obsolete anyway in some environments, and plenty of people using POST and GET only. REST has really stolen the http protocol and has used it for an originally unintended purpose. I'm kind of getting a bit sick of developments' collective claim that one path is best practice and another isn't, with no statistical analysis/mathematical proof that one way is, in fact, better than another. On Mon, Mar 27, 2017 at 2:32 PM, Greg Keogh <gfke...@gmail.com> wrote: I think we'll stick with the RPC style of call and not go with a RESTful interface, and anyone that cares that much about it in an interview can go and get a pointier hat. Oooh, I'd still try to do things the restful way and follow the "standards" (cough, ahem!), or "conventions". If you want to do it the RPC way then you should probably use a SOAP service with real contracts. You might run into libraries that expect you to follow the "conventions", I dunno for sure, but I'd play it safe -- GK
