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:
- 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.