Coming from the .Net world to django and writing web services for consumers is a welcome change. .Net SOAP web services require a lot of designing and work to make them expressive yet perform well – whereas django REST services flow much more easily. However, whereas in .Net you normally throw Exceptions which turn into SoapExceptions – with django and REST I find I have to write documentation for clients/consumers explaining how to check results:

• Success
• Failure case 1
• Failure case 2
• and so on…

So, one of the painful aspects of REST is there is no predefined concept of an exception.

Another painful thing with REST I need to get used to is there is no ‘framework’ for calling REST services. Looks like an opportunity to define a common calling convention – but the drawback is I’m dictating customers/consumers use a factory-h library – because the calling conventions are well defined. If there is one thing I’ve learned – let the customer/consumer write it – guide them, but don’t write it for them. The reason being, there’s always something they want, or think they need, that I never would consider a priority.

The end result for me is that REST is quicker to write, but requires more discipline.

After kicking myself for not implementing a versioning scheme in the first .Net soap web services I designed, it’s something I started doing since. I see it over and over with the other services I’ve worked with like Amazon. I like putting the design year into the REST url: domain/2008/service-name/operation/instance

Years seem much easier, and let you know how long they’ve been baked in than version numbers.

For those of us not using django 1.0 (yet)

Newforms are great, and ModelForms will be a welcome release. However, I find I can’t utilize the over simplified workflow:

myform = MyForm(request.Post)

myform.save()

because I have to process one or more fields before saving. But there aren’t a lot of explicit examples – for some strange reason, you are required to call .is_valid() on the form before trying to access the clean_data, like this:

myform = MyForm(request.POST)

myform.is_valid() # this creates the clean_data dictionary

attribute = myform.clean_data['attributename']

Seems like the sort of thing I would code an exception into the clean_data accessor – ‘you must first call is_valid() before using’. Maybe that’s just me.