ASP.NET WebAPI + Soap

WEB API is Microsoft's answer to REST based apis. If you want SOAP, go with WCF.

You should consider looking at ServiceStack which allows your same service to support REST + SOAP APIs, although since SOAP only works over HTTP POST it has some restrictions

Add ServiceStack Reference

As an alternative to SOAP, ServiceStack offers a better alternative to WCF's Add Service Reference which can generate a typed API from a URL using Add ServiceStack Reference feature that's built into ServiceStackVS.

Advantages over WCF

• Simple Uses a small T4 template to save generated POCO Types. Updating as easy as re-running T4 template
• Versatile Clean DTOs works in all JSON, XML, JSV, MsgPack and ProtoBuf generic service clients
• Reusable Generated DTO's are not coupled to any endpoint or format. Defaults are both partial and virtual for maximum re-use
• Resilient Messaging-based services offer a number of advantages over RPC Services
• Flexible DTO generation is customizable, Server and Clients can override built-in defaults
• Integrated Rich Service metadata annotated on DTO's, Internal Services are excluded when accessed externally

WebAPI and WCF both promote RPC method signatures

What's interesting is that despite WebAPI ApiController methods having taken the same RPC approach as WCF in using C# RPC methods to create and define chatty web services with, that they're still not able to support their own SOAP standard made by the same company.

ServiceStack supports REST, SOAP, HTML and MQ endpoints with same service

This is a testament to ServiceStack's message-based design which offers numerous advantages not withstanding being able for the same service to support multiple endpoints and formats including REST, SOAP and MQ endpoints as well as generating server-side or client-side HTML websites if you need it. Here's an example of a rich Northwind database editor that because it was built with ServiceStack automatically enables a typed REST APIs that is able to be called with rich native Desktop clients, Mobile Apps and Single Page Apps.

SOAP is still a poor option for remote services

Although despite supporting SOAP for interoperability, accessibility and backwards compatibility reasons, we don't recommend it for building web services platforms with as it's un-necessarily complex, brittle, slow and verbose and there are much better alternatives to use. I explain more in detail in my interview on InfoQ.

WebApi does not support SOAP out of the box, indeed. But it is a quite flexible framework and you could "adapt" it to handle SOAP: nothing prevents you from manually parsing the received SOAP messages (they are plain XML after all) and manually generating the responses as XML strings, then sending them with the approproate content-type header (you could even write your own content formatter for this).

Depending on your needs and your existing codebase, this may be worth the effort or you may want to use a more SOAP-firendly technology such as WCF or the already mentioned ServiceStack framework.

To quote Scott Guthrie: The last few years have seen the rise of Web APIs - services exposed over plain HTTP rather than through a more formal service contract (like SOAP or WS*).

So I would say no.