Or you could use http://www.servicestack.net to host your same single web service on JSON, XML, CSV, JSV, HTML, SOAP 1.1, 1.2 endpoints out of the box, with no config or code-gen for free on .NET or Linux/Mono in ASP.NET or in a Console/WinService with HttpListener with C# or easily with F#: http://www.servicestack.net/mythz_blog/?p=785

ServiceStack also includes the 2 fastest text serializers for .NET (JSON/JSV) - many factor of times faster than all of the JSON serializers in .NET: http://www.servicestack.net/benchmarks/

And if you add the ProtoBuf plugin you get .NET's fastest Binary serializer as well: https://github.com/ServiceStack/ServiceStack/wiki/Protobuf-f...

After using .NET for a while, I felt that the Java platform has made a series of better choices regarding modularization and the support of web programming (API or something else).

JavaEE 6 can be whatever you want it to be (flexible):

- JSF -> similar to ASP.NET WebForms programming paradigm

- Servlet/JSP -> a more simpler/lower-level MVC

- Async a'la Node.JS via Servlet 3.0 Async feature

- JAX-RS -> RESTful (Atom, XML, JSON, and more)

- JAX-WS -> WebService (1.1, 1.2, whichever)

- JPA 2.0 -> ORM (regardless whether you want ORM or go back to JDBC)

And in case if you need something similar to Rails/ASP.NET MVC, Spring MVC 3.x is just another library on top of Servlet/JSP stack.

The best part is that almost all of them (except JPA 2.0 and Servlet 3.0 Async) are just a thin facade to communicate with client-side, whatever that'll be so you can re-use your business logic regardless (except for Servlet 3.0 Async, of course you have to make sure everything else is Async as well).

EJB 3.x is less popular these days unless you need a specialized needs such as having to support Stateful or a Transaction that spans to a series of persistent and message queue actions. But the tools are there, separately and contained, if you ever need it.

It looks like Microsoft is ramping up a little bit and following the Java EE 6 model.

I'm right in the middle of making this decision as well. We are aiming for a RESTful APIWCF suppo Service to perform CRUD operations on JSON serialized EF objects. On the client-side HTML5/JS. MS has made there intentions quite confusing, but from atleast one article I read MS doesn't intend to extend support for WCF past years end, and that WebApi is the way to go..... so I don't know... I'm in the midst of trying out WebApi now.

WebAPI is about to be merged into the new MVC 4 release.

Announcement: http://wcf.codeplex.com/discussions/319671 MVC4: http://www.asp.net/mvc/mvc4

Simple. Use WebAPI if you want a public-facing JSON web service. Use WCF if you want a private internal SOAP web service. WCF was meant to be consumed by other .NET classes in LOB apps, not Javascript.

It's kind of amazing. A whole article about something called WebAPI and not a single link to a document that would describe what WebAPI really is. This is HTML, right?