HTTP method based service resolution

Idea created by Ben.Deutsch on Oct 5, 2017

    I swore I created this idea before, but I can't find it so I'm posting it again...

    The gateway should take into consideration the allowed HTTP methods during service resolution and fail next when not permitted (similar to SOAP action not defined within a WSDL).  This would allow two important things; first overloading of REST urls so that POST, GET, PUT, DELETE, etc method handling would no longer have to cohabitate in the same policy allowing for less complex policies; and second that method not allowed could be caught in the catch-all instead of sending a generic gateway error message outside the control of the gateway administrator (though there are workarounds, either pre-screen all requests in the message-recieved global policy fragment adding overhead to all processing and surfacing access to the ssg database or enable all methods for all non-soap services and do method validation in every one of those services; neither option of which is pretty for somthing that should be automated).

    As a practical matter, this would have little impact on existing services because it would only change the failure mode from a generic gateway error to the catch-all policy and would have no effect on existing successful policy execution paths.