Make sure you use the right method

Pop quiz:

What is the difference between HTTP POST and HTTP GET?

If your guess is that GET sends data via the query string while POST send data in the request’s body, you are… absolutely correct.  And I hate your guts.  Why is this?  It’s not that what you’re saying is wrong by any stretch of the imagination.

Idem-what?

I hate you because while GET and POST do send data differently, that’s not the biggest difference between the two.  The biggest difference is that POST methods are idempotent.  What does this piece of programmer-ese mean?  How many times have you seen something similar to this Chrome form?

 

confirm form resubmission

On poorly designed websites, you probably see it a lot.  Web development newbies will often ask how to disable this page (or its Firefox equivalent).  There’s a really simple answer for this:  you don’t.  That warning is there for a reason.  You will see that warning every time you hit the back button to go to a page that was requested via HTTP POST.

The reason for this is that POST requests aren’t idempotent.  Idempotent is just a fancy word meaning that something won’t make changes.  As the HTTP 1.1 specification says:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Suppose we’re writing software for a web forum, and we have a URI /forum/submit-message.  If we send data to this form, it will post a message.  Now, imagine that after submitting a message, the user visits /forum/view-message and then hits the back button.  They will go back to /forum/submit-message and send the same message over again if you were to use HTTP GET instead of POST.  However, if you were to use POST, that would be prevented by the maligned “Confirm Form Resubmission” page.  Sometimes annoying things can be useful, eh?

What’s the point?

The point is that nothing is more annoying than a website that uses GET and POST incorrectly.  And you don’t want to lose users by using the wrong one, do you?

You need to worry about deployment

Oftentimes, people used to using PHP or Classic ASP will give up on Python because deploying Python scripts isn’t just a simple matter of copying and pasting files.  Usually, this isn’t because Python is making their lives difficult.  It’s more a matter of not thinking about how to deploy your scripts ahead of time.

Now, I’m far from a highly experience programmer, but I can tell you one thing.  Deployment is a detail that will come back to bite you if you don’t spend a little bit of time on it up front.  So here are a few pointers I’ve come up with after experiences in deploying Python scripts for web apps.

1. Batch/Shell scripts are your friends.  A common objection is that a person just doesn’t have time to learn a new tool for deploying.  I have two responses to this: 1)  Drop that attitude otherwise you’ll never get anywhere as a programmer and 2) Don’t use them if you really don’t want to!  While batch and shell scripts aren’t the prettiest options, they’re a lot better than having nothing to automate deployment at all.  In fact, for the basic one or two page webapp, you can’t really do much better.
2. If you invest some time in Continuous Integration, you won’t regret it.  I know what you’re saying.  Continuous Integration is a Java thing.  It’s too complicated.  And you’d be right to a point.  However, I would argue that making sense of the complication is worth your time.  It’s way too easy to deploy something that doesn’t work because somebody forgot to run their unit tests.
3. Site-wide packages are evil.  If you aren’t already, you should really be taking advantage of virtualenv.  That is, unless of course you enjoy troubleshooting weird ImportErrors because of that egg you installed using the setuptools develop command a month ago and forgot to remove.
4. Don’t underestimate the value of good docs.  Having good documentation is just one of those things that don’t become obviously necessary until it’s too late.  Don’t leave yourself trying to figure out how that one function you wrote a year ago works.  Write documentation as you go and use a tool like sphinx to turn it into a webpage.  This ties in with point 2.  Using Continuous Integration will make doc generation that much easier.

Admittedly, doing this stuff can be a pain.  And you might get scorn from co-workers for not having something ready the next day.  But it will be worth it.  You’ll be surprised at how much time you’ll save in the long run.