Soap in your eyes can be painful

Mon Aug 18, 2008

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.