I've often found Python's context managers to be pretty useful. They make a nice interface that can handle starting and ending of temporary things for you, like opening and closing a file.
Posted by: Jeremy Satterfield
in
development
on 2014-02-28
Anyone running an API that can be reached by the outside world should most definitely be concerned that someone might pummel their server by making a massive amount of requests to that one endpoint that requires a bunch of on-the-fly calculations. Enter Django Rest Framework's throttling. It allows you to easily configure the framework to stop allowing requests from a user once they've made so many requests in a period of time. Whether you're concerned about requests over a sustained period of time or in short bursts, rate limiting with throttles will handle it.
When working with Django Rest Framwork a few months back, there were a few road blocks that we ran into. Rest Framwork is awesome with most models for providing a simple CRUD API, in any (or multiple) serializations, with authentication and permissions. Sometimes, however, things aren't so simple. Things get ugly. Framworks get abused.
I'm a big fan of proper unit testing with mocking. So I'm pretty disappointed when we run across a unit that is not only not mocked properly, but results in real-world consequences outside the testing environment. One case we've run into couple of times now is tests that are making actual outbound HTTP requests to remote servers. Since clients don't necessarily like getting fake information posted to their servers every time you run tests, I figured this was a good time to get to the bottom of this.
I've been huge fan of Django's class-based views (CBVs) since I first tried them out in Django 1.4. While they're much more complicated then the classic function based views, once you understand how they work, they're much more powerful, flexible and allow for DRYer code. I highly recommend anyone who hasn't delved into CBVs take a look at Class Class-based views or GoDjango.