Every once in a while I run into something I need to debug from the network up. Most of the time I can do this using Wireshark but there are a few instances where what I'm really looking for is a man in the middle proxy. I usually find an alternative way to debug what I'm working on but recently I decided to find a combination that worked so the next time I can use it.
Most of the time what I'm working on when I need a proxy has something to do with SOAP and there is actually a MITM proxy in SoapUI but it doesn't have support for HTTPS. If you are working with SOAP and can use HTTP then SoapUI is a great tool. If that doesn't fit the bill then Paros proxy does a good job.
I generally don't recomend using SOAP instead of REST but I have been required to use SOAP so much now that I think it is inevitably going to be a requirement for a long time for certain projects. So when I noticed a question on stack overflow about using SOAP on the Google App Engine I thought it might be a nice exercise to see how easy it is to get fringe toolsets to work in the GAE.
While working on an SOAP service I needed to create a number of clients for different languages. This would normally not be that big of a challenge except that the SOAP service had custom headers for doing authentication. Because of the complexity in setting up Axis to use WS-Security the choice was made to do authentication by adding a few out of band SOAP header values. The first few implementations went fine but then I came to C# and had a problem.
Recently it seems like the SOAP vs REST debate is heating up. Most of the debate seems to be leaning toward convincing people to not use SOAP based on its increasing complexity. Different people have different views on what REST is but in general if you look at the SOAP specifications or SOAP Standards and Web services and then look at the REST specification, REST for the Rest of Us, or REST you see that in general there is a lot more complexity to SOAP and that is just SOAP itself and not any of its extensions. Here are some good articles I've found that should give you insight into the debate:
After looking over the above references you may be interested in looking at Programmable Web's API list and see what others are using. The majority of the public services listed offer REST interfaces with some offering both REST and SOAP and very few offer just SOAP. Even though REST seems to be in favor now I believe there are still plenty of areas where SOAP makes sense when you have resources to devote to feeding and caring for it.
Tags: SOAP, REST, web services