Blog of Dave

I experienced something new with ColdFusion webservices today and I thought I would share.   We have a webservice API to Ryan Everhart and Robert Froehling's project codeShare which allows our users to insert code in their blogs from the blog entry editor which is then nicely formated on their entry.

Apparently in early February, they made a change to that webservice in which they added an optional argument to the end of the arguments list.  For the past month and a half since their change, our application continued to purr along passing all but the last argument, and there were no errors and no problems... until Sunday night!

Sunday night, Aaron and I did a complete version update to InstantSpot in which we restarted the application instance for the first time since we launched the site last fall.   At that point (we found out much later), our API to codeShare had stopped working.

In debugging the problem today I instantiated the webservice and tried to manually pass a test code submission to it. When I did, I got an error similar to this:

Web service operation "ourMethod" with parameters {"[parameter 1 value]","[parameter 2 value]","[parameter 3 value]","[parameter 4 value]",} could not be found.

I dumped the webservice and could clearly see our method and was able to quickly rule that out, leading me to believe that something had changed with the arguments.  

When I approached Ryan about the issue, he was sure that they hadn't recently changed anything (he was right!).  When he shared the code with me however, we saw that our arguments list didn't match theirs.  By tacking on the last optional argument, things began immediately working again.

Why is this interesting?  Well, I felt that it was notable that even though they had changed their code, their CFC on their end didn't really care whether the last argument was their.  It managed it with the same behavior that it would with a component instantiation and call to the method.  Where it seemed to matter was on our end, and our server was balking at the fact that the list didn't match.

I suppose this makes sense since webservices do not allow name-value pairs to be passed in arguments to methods.  That means that if you make the 3rd of 5 arguments optional in your webservice, there is no way to explicitly skip that one and move on as the webservice will apply them in the order that they are passed to the arguments that are available.

Given that information I would consider it good general practice to always make the arguments of webservice methods required="true".