I blogged yesterday about the LinkedIn API and it’s lack of support for .NET developers and lack of debugging info. The post was made partly due to our frustration of first spending 1 1/2 days debugging an obscure error that ended up being an error in the API documentation, followed by another full day of debugging the second generic error that resulted from a misconfiguration on our account.
I still think that a company that offers an API should have a dedicated developer/staging area that provides usefull debug information to help developers along. I also believe LinkedIn should provide some support for .NET developers…at least some form of sample code.
Having said that, i want to make clear that the LinkedIn API Developer, Taylor, who is supporting the API has been very helpful to me from day one. He has tried to offer suggestions and sent some untested C# code to try and get me through the issues. From a support persepctive, i give them high marks….much better than working with Google or Yahoo’s support team.
I’m happy to say that, having gotten those 2 errors resolved, we have successfully been able to implement the API in our C#/.NET application. Therefore, if your trying to implement the API in your own .NET environment, and need some help, drop me a note and i’ll be happy to give you some pointers on things that we ran into and what we did to overcome them.
This has been an interesting exercise in implementing a full REST API versus SOAP API. For .NET developers, a SOAP interface with the WS_security features offer a far cleaner and easier API to work with, because much of the complexity is taken care of inside the development tool itself (visual studio). There is no need to think about creating custom authentication headers and dynamically altering URL’s….you just get a nice list of API methods you need to implement.
However, for scripting languages such as Ruby or PHP, which offer limited support for SOAP, I can see why the REST API is much easier to work with and understand. In those scripting languages, dealing with WSDL and the intracies of a SOAP message is much more complex because the development tools don’t work well with them. a REST interface becomes much easier to hand code and deal with.
Ultimately, I think a company offering an API should support both…giving the API consumer more choices and flexibility. To that end, we offer our own WildFire API both as a SOAP and REST interface.
After all that frustration though, i’m happy that we were able to implement the API, and things seem to be working smoothly now.