Recently Microsoft released the first preview release of their REST API for Visual Studio Online which they have named Visual Studio Integrate.nbsp First off this is yet again another great example of MS being far more open with tools and letting development teams get the experience they need without having to hack into backdoors.nbsp Im really loving where theyre going and Im looking forward to utilising ASP vNext and Roslyn for example.
But anywho someone always has to have a mean and today thats going to be me.nbsp There are a couple of very small things that centre around OAuth that are a bit of a pain.nbsp The way the VSOI team have set it up is that when you create a consumer application for the REST API you set up a Callback URL for the OAuth server to return the user back the consumer application with an authorization code so that it can grab an access token.nbsp Easy except that it must be an HTTPS address and it must be on port 443.nbsp Still not a huge gripe there are many ways to set up IIS Express to accept requests on 443 but they arent the most undaunting steps to follow so that you can debug a consuming application.nbsp The real bug bear I have is that when you redirect the user to the authorization URL it must contain the callback URL you entered as a GET parameter and it must match EXACTLY.
Now Im a stickler for DRY development and if I can get out of writing code I will.nbsp So when I first went to try and use the VSOI API I thought sod it lets just use DotNetOpenAuth and then I can use Microsoft.AspNet.WebPages.OAuth to do all the hard work for me.nbsp So I coded up a custom OAuthProvider popped it in and got this:
Microsoft.AspNet.WebPages.OAuth puts on the end or the URI the name of the provider so that it can it can figure out which provider to call to get an access token so we already have to chuck that idea in the bin because it will never call a URI that is EXACTLY the same as the one Im calling.nbsp This isnt to say that I couldnt put that GET parameter in the callback URI but its one of those things I would think need to be kept clean.
One thing that it totally kills however is that timeold easy to put in bit of functionality that improves user experience 10 fold when using secure pages post login redirect from the page the user was on.nbsp Its such pain in the ass to log in to a site then be shoved back on the home page because the developer didnt think the user would want to go back where they were before they logged in.nbsp Not this time though what would be the point in hardcoding a return URL
I have to say that these are two very tiny gripes that can be worked around but other APIs are quite happy to live with.nbsp Im going to try and raise a user voice for it and see how I get on.nbsp Other than that the API is gorgeous and when you have one query working it very easy to fly through any subsequent ones.nbsp Im in the process of building a portable class library wrapper in .Net for it so please do contribute to the project.