This is a reminder to myself and others that the biggest local DC-MD-VA Hamfest is coming to the Timonium fairgrounds March 27 and 28. I’ll try to hit the Hamfest on Sunday. Hopefully I’ll be able to pick up some cool and obscure hardware for next to nothing.
I don’t hold a ham radio license, though I have thought about it in the past. I lack the funds and free time for another semi-expensive hobby though.
A discussion on the Atom Wiki should make it possible for clients that lack PUT and DELETE to fully implement the Atom API. If folded in to the next revision of the API, this enhancement will make J2ME Atom API clients a possibility. As Russ pointed out previously, J2ME does not include support for PUT or DELETE. But why get rid of SOAP?
I don’t want to make things too hard on Atom API server implementers. At the same time, I love the flexibility of being able to choose between coding a client with GET and POST (and hopefully PUT and DELETE) or SOAP. Sometimes the former makes more sense. Other times it’s the latter.
If I wanted to whip together a quick client demo to impress my friends, I would probably point WSDL2Java or Visual Studio .NET at a WSDL file. Then I could whip together a working Atom API client in just a few minutes in front of their eyes. They would get bored while I implemented things on the HTTP level. I’m sure that Mark or Sam could whip something together at that level in a few minutes, but not I. (On a side note, check out this post in Sam’s blog and this sample C# client on atomenabled.org)
To demo things, I could easily point my client at Blogger or Typepad, two services with significant user bases, and both with SOAP implementations of the Atom API. It’s times like this that SOAP shines.
So why do we have to get rid of it?
It seems that many people are against having SOAP in the spec at all. I can understand where they are coming from. On some platforms, it would be fairly easy to implement SOAP on the server side. On the other hand, if your chosen platform does not have a SOAP toolkit that you can use, implementing it from scratch is non-trivial.
Here’s what I think: SOAP should stay. It adds more flexibility for consumers. In an ideal world all clients would interact with the API using GET, POST, PUT and DELETE. Ideally, clients that lack PUT and DELETE would interact with the API using GET and POST possibly as outlined on the wiki. Alternatively, I would like clients to have the option of using SOAP to interact with the API. SOAP support SHOULD be implemented on the server side, but should be no means be neccesary. It would be cumbersome to make SOAP support a MUST, but there would be fewer SOAP implementations if support is listed as MAY. If several of the big players continue their SOAP support, writing a SOAP client will still be rewarding.