The user group in New York City last night was great.  The turn out was around 85 people and the response, attentiveness, and questions were very good.  This talk is a hell of a memory dump since I cover so many things.

The name of the session was “Integrating Search: An Adventure in Dependency Injection” and I cover not only the APIs of the three major search engines, Bing, Google, and Yahoo (soon to use Bing), but also some provider design, dependency injection, and custom controls (both windows and web).

I also showed off my new FluentSearch DSL which I’ll have on this site very soon.  I talked about this session and the FluentSearch DSL in a previous posting regarding the Philly Code Camp, so you can go there to read more.

I want to cover an answer to one of the questions last night since I wasn’t able to answer it off the cuff and gave the attendee an honest, “I’m not sure”.  The question was regarding the WebGet attribute that I used to decorate the operations in my service contracts in order to consume the REST APIs of both Google and Bing.  The ResponseFormat argument of this attribute had the optional settings of either XML or JSON.  This determined the format for the data that the search engine API would return and instruct WCF how to decode it.  The exact question was regarding the RequestFormat argument of the attribute and what it would be used for in this scenario.  The answer is that it wouldn’t be used so its value wouldn’t matter.  The RequestFormat argument determines the format used when the operation is used to expose a service, not to consume it.  In all my usage for this talk, I was using this service contract for consumption of the external API so ResponseFormat is all that was important.  If I was actually writing a service to implement my service contract and would provide my own implementation of that operation, then the RequestFormat would determine what format of data I would expose through that operation.  But once again, I was only using my service contract to map to a REST URL that was exposed by another API so it was only in the context of a proxy-based consumption.

My sincere apologies for not having the answer to this question off the top of my head.  This talk covered so much that when the question was asked, I guess my head was elsewhere.  Thank you to whoever it was that asked it because it is definitely information that I should have covered in more detail.

As always, kudos to Andrew Brust for running a great group and inviting me to once again be a part of it.

You can get the session material from the Downloads section of this site.

Until next time…