.Net options for JSON API?

Question

I need to create a .Net api that will return JSON that will be used by mobile applications.

One approach is to just use an MVC app and have my controller return JSON, so going to a url.com/controller/action/params would give me my JSON.

I've heard that creating a WCF Service is also a good choice. I don't know much at all about WCF, though.

Are there pros and cons to each one? Is one more reliable to be used as a service that returns JSON only?

Answer 1

Another contender is ASP.NET Web API which uses WCF in self hosted scenario.

There are pros and cons but it all depends what you need now vs. latter, what is your level of expertise, technology commitment and what are the design trade-offs.

It depends what you mean by reliable. One technology is not necessarily more or less reliable. There are many factors that go into reliability.

These are some of the few pros/cons in no particular order, preference or completeness.

ASP.Net MVC / WebApi / ServiceStack

Pros:

• Setup and running within minutes for basic scenario (have URL get some JSON data)
• Simple to configure.
• REST setup straight forward.
• Complete control over routing.
• JSON native support (ASP.NET Web API can automatically serialize
  your model to JSON, XML, or some other format, and then write
  the serialized data into the body of the HTTP response
  message.)

Cons:

• Cannot describe your service to a consumer: no api like WSDL exist as of yet that can tell the client data types, operations and service requirements
• Transport security only - point-to-point security
• No message level security
• No Service Discovery protocols (as of now)
• No Message routing
• No multi-protocol support e.g. tcp
• Single hosting scenario (IIS - this can be a pro too)

WCF

Pros:

• Multi-protocol support
• Transport and Message security
• Highly configurable and inter-operable
• Very extensible
• Supports various messaging scenarios e.g. routing, duplex, pub/sub, queuing, etc.
• Lots of knobs for shaping messages and internal workings
• Wide variety of hosting scenarios (IIS/WAS, Windows Service, Console)

Cons:

• Steep learning curve
• REST story weak (yes webHttpBinding exists but try explaining to someone TemplateURI and WebInvoke/Web get and BodyStyle)
• Lots of knobs

Answer 2

If all you are looking for is a service, then I would suggest something like WCF. However, WCF is cumbersome, so I would suggest something simpler like ServiceStack. It allows you to create your service using basic POCOs. It also comes built in and ready to respond with JSON/XML/SOAP (no extra actions on your part)

Answer 3

I would really go with the WCF approach. It will give you more flexibility and allow you to run the service using many different protocols, not only HTTP, for example.