The HTTP method reflects a verb (action) that applies to current request, however the limited number of HTTP verbs does not cover all use cases that applies to HTTP API. So that usually leads to mixes of HTTP verbs and actions that better reflect use case, e.g. publish, activate, block, send, subscribe, etc. Thus it is recommended to limit HTTP API design to commonly used methods (GET/POST) only. Anyway CRUD HTTP API doesn’t look any better with HTTP verbs vs URI, thus consistency in API design is preferred.
There client side libraries that rely on ability to communicate with RESTful server side API, thus methods like PUT, DELETE become important. Rarely used: PATCH, OPTIONS. Unlikely to be used: CONNECT, TRACE.
There is options attribute defined in MethodHandler (that comes from request.options). This attribute conflicts with HTTP verb.
Refactor MethodHandler and BaseHandler to rename self.options to be self.o
Use method self.http_options to handle OPTIONS verb.
It is recommended to use package base handler, e.g. MembershipBaseHandler (see an example here). This way you can extend/override the existing functionality provided by BaseHandler (or MethodHandler) a way you like, e.g. for API web handler you might have something like this: