It has taken me far too long to figure out all the minute details of how to apply authentication to gRPC-based services, how to do that using the HTTP/JSON grpc-gateway, and then how to run a gRPC server and a grpc-gateway side-by-side using the same service instance in a way that makes sense to me. There’s a surprising amount of detail that is not documented and there are a few gotchas for the unwary traveller....
Last year I blogged about a neat trick in Django to have multiple views per HTTP verb. Since then I’ve been playing with RESTful applications and decided to see if there was a nicer way to expose “resources” in Django. The following is what I’ve come up with so far. Listing: router.py from django.http import Http404, HttpResponseNotAllowed def get_handler_method(request_handler, http_method): try: handler_method = getattr(request_handler, http_method.lower()) if callable(handler_method): return handler_method except AttributeError: pass class Resource: http_methods = ['GET', 'POST', 'HEAD', 'PUT', 'DELETE', 'OPTIONS', 'TRACE'] @classmethod def dispatch(cls, request, *args, **kwargs): request_handler = cls() if request....
The following is just a reminder to stop me from getting confused ;-) GET Used to fetch a resource. The server sends back a representation of the resource in the response body. Safe operation (see below). DELETE Used to delete a resource. The response from a server may contain a status message or nothing at all. It is usually nice to send back at least a 204 (No Content). Idempotent operation (see below)....
HTTP verbs are not used to determine the route to a view method by deliberate design in Django. Sometimes I find it useful to be able to specify different methods for the same url pattern - one per HTTP verb. The Django book contains an interesting example of how this can be done using the django.conf.urls.defaults.url method to separate POST from GET processing. I’ve extended the example to provide handling to cover the standard HTTP verbs....