Creating an web API in ASP.Net

Question

Hi,

I'm looking to create an API for a website I have built. The API will be built in ASP.Net - probably using VB and will need to be consumed by multiple platforms including PHP.

I've read a bit about REST vs. SOAP APIs and am confused about which route I should go. I also need some examples and frameworks I can use to get started.

Thanks, Josh

Answer 1

REST is a simple architectural style for designing APIs that is easy to consume from multiple platforms.

SOAP is more complicated and but does provides standards for many extra protocols such as transactional reliability, messaging, security, authentication etc.

Unless you are writing a complex enterprise messaging system then REST will probably be fine (but don't quote me on that).

You might want to look at the REST in WCF web pages from Microsoft. http://msdn.microsoft.com/en-us/netframework/cc950529.aspx.

Answer 2

Just create an Asp.net Web Service (a separate project or include web methods within the same Asp.net web forms application) or a bit more advanced WCF Web service (can also be contained in the same app or separate). It also depends what you want to do in terms of security.

If you created separate projects for your Asp.net web forms application, you can easily use those projects/assemblies with your service.

Answer 3

Is your API going to provide more functionality than is already in your web site? If not, why not just make your existing web pages easy to access via code. That way you don't need to support two distinct interfaces.

If you think about it, your existing web pages deliver html content which is relatively easy to parse. Those pages contain links to the other functionality in the site. The pages contain all the data the user currently sees.

As long as your existing website does not make use of session state, you may already have a RESTful API.

Answer 4

There are a combination of technologies and techniques you could use to build these services:

• SOAP Services - If you're going with SOAP-style services, you would want to go with either WCF or ASMX services.
• REST Services - If you go with a RESTful format, you have even more options. You could go with an HTTPHandler, the ASP.NET MVC framework, or WCF

Some of the things you need to think about when evaluating approaches:

• Userbase Technology - SOAP services are preferred in the enterprise with Java or .NET clients because Java and .NET technologies can quickly and automagically create the local bindings to let applications communicate with remote services as if they were local objects. If your consumer base tends more towards PHP/Ruby, the tooling is not as prevalent and these crowds tend to prefer the RESTful model. The auto-binding is due to the presence of a WSDL. The adoption of WADL to describe RESTful services is slowly narrowing this divide.
• Content Type - More than just the service style, what type of content are you going to provide and what will it be used for? If your clients are going to consume this data directly in the UI, JSON might be an alternative to XML. If they're integrating it into more of the middle tier of their applications, XML is probably a better candidate.
• User Provisioning and Management - Once you've made a decision on REST vs. SOAP and content type, the frameworks (WCF, MVC, .NET) will take care of a lot of the work for you. The tough part then becomes user provisioning, management, authentication, etc. Do users use existing credentials or additional credentials, are they provisioned in-band or out-of-band, how do you throttle API consumption. Warrants anther post entirely.

Once you've digested these options, I'd recommend that you look at some of the frameworks and see which one you're most comfortable with. As there are multiple ways to get the job done, you should find the one that best suits your needs and capabilities. Additionally, for both the long and short term, you might want to begin experimenting with a web service testing tool - SOAP UI is my recommendation. You can use SOAP UI to consume existing web services (e.g. Flickr, Twitter, Amazon) in both a SOAP and REST format and get a sense of how successful APIs have been implemented and function on the wire. You can also use this tool to perform functional and load tests of your services, once you've built them.

Answer 5

From this month's MSDN Magazine:

RESTful XHTML: RESTful Services with ASP.NET MVC and XHTML

This article describes how to use XHTML and ASP.NET MVC to implement REST services. Aaron Skonnard