Through the Interface: Exposing a RESTful web service for use inside AutoCAD using the ASP.NET Web API Part 1

May 2015

Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30


« Adding snapping to the AutoCAD MRU browser using WinRT | Main | Exposing a RESTful web service for use inside AutoCAD using the ASP.NET Web API – Part 2 »

April 04, 2012

Exposing a RESTful web service for use inside AutoCAD using the ASP.NET Web API – Part 1

As promised, here begins the technical portion of the series on moving application functionality to the cloud.

As suggested, we’re going to take code from a couple of previous posts and put it in the cloud (although not immediately – first we’re going to move it to a local web-service, consume that in AutoCAD, and then look at our various cloud-hosting options).

So why did I choose these two pieces of code, in particular? A couple of reasons: firstly, they both implement “behind-the-scenes” algorithms that are independent of AutoCAD – a typical piece of business logic that companies might choose to place behind a web-service, in my opinion – and, secondly, they are both implemented in F#, which gives us an opportunity to abstract away technology from the user (it removes the need to deploy a separate class library built using F# from our application).

We’re going to use ASP.NET for this effort, which is Microsoft’s application framework for creating web-sites and applications. To expose our web-services (as opposed to a web-site), we’re going to make use of the ASP.NET Web API feature, which is brand new in the as-yet-unreleased ASP.NET MVC 4.

Let’s first resolve some acronyms…

ASP.NET is the .NET-based version of ASP, which standards for Active Server Pages rather than Application Service Provider.

ASP.NET MVC is a framework that sits on top of ASP.NET (which perhaps makes it a meta-framework or even a meta-meta-framework, if you consider the CLR :-) allowing web developers to use the Model-View-Controller architectural pattern (a type of design pattern) to implement web-sites. MVC encourages a clean separation of data (the model) from the way it is presented (the view) and interacted with (the controller).

It’s not specifically interesting to us in today’s post – where we’re simply using MVC 4 to get at the Web API feature – but it’s generally an interesting paradigm for web-site exposure.

And the hot news around MVC and the Web API is that they are now open source, which means you can browse and even contribute to the source, should you be so inclined.

So why use an unreleased (albeit open source) technology for this post? The short answer is that the Web API makes it incredibly easy to expose RESTful web-services. I’ve briefly mention REST a few times in the past, but it’s been a while. I fully expect to be making increasing use of web-services implementing REST over the coming years, though.

I won’t go into the steps needed to install ASP.NET MVC 4, but I will just say that there are a few different ways of getting it, right now: you can install the Beta for Visual Studio 2010, you can install Visual Studio 11 Express Beta for Web, or you can install Visual Studio 11 Ultimate Beta. I was a little unlucky, in that I had Visual Studio 11 Professional Beta installed – which meant I lost some time trying to install MVC 4 Beta on to of it, before I realised I actually needed to upgrade to Ultimate – but I got there in the end. One thing to bear in mind for later: at the time of writing it seems the Windows Azure .NET SDK doesn’t support Visual Studio 11, so I may have some hurdles to face when I get to that point. So sticking with VS2010 may prove the best option, for those of you who haven’t yet gone with VS11 (they can sit side-by-side, anyway, which is how I’ll probably manage the Azure deployment).

With MVC 4 installed, I went ahead and looked at the project types to create. If you want a good foundational article on using the Web API to use C# to expose web-services, take a look at this one. In our case, we want to use F# on the server, so I ended up choosing an online project template that gives us both C# and F# in an MVC 4 app:

New F# Web API project

We then get to specify that we want an Web API project and that we don’t (for the purposes of this simple example) care about testing:

Choosing a Web API project

This creates some nice boilerplate code that makes it really easy to expose our web-services. In the next post we’ll flesh out this project, hooking it up with our existing F# code to expose a couple of web-services for consumption inside our AutoCAD application.

blog comments powered by Disqus


10 Random Posts