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* >
