Does WebAPI support SOAP? I'm trying to write a SOAP Server in MVC4 and whilst I can do it in WCF it seems that WebAPI is replacing this but I see no ways to utilize SOAP in this yet, just JSON / XML using a REST Style interface.
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.
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.
WEB API is Microsoft's answer to REST based apis. If you want SOAP, go with WCF.
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.
You might want to look at ServiceStack which should support both SOAP and REST in one interface without any hassle. It claims to be a better match than WebAPI for web services.
I can't claim to know everything about the difference, but the problems they claim are inherent in the Web API approach I can say from experience are real - API evolution (inevitable in a real project) is quite tricky in web api. And of course, web api doesn't support SOAP.
It is not like Wed API supports SOAP but due to SOAP is just a standard that uses XML and it travels throw HTTP you can use Web API to expose a POST Service to read the XML and find the nodes you need using XPath and then Deserialize the nodes to objects.
First, you need to add XML support to the ConfigureServices
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc()
.SetCompatibilityVersion(CompatibilityVersion.Version_2_1)
.AddXmlSerializerFormatters();
}
Then in your controller, you just need to add a method that receives an XMLDocument and with XPath search for the node you are interested (Basically removing the soap envelope, the header, the body) and then you can deserialize the object.
In my case, I add the service reference using the WSDL and with that, I deserialize the object.
[HttpPost("reservationxml")]
public void CreateReservationFromTSW(XmlDocument soapCreateReservationRq)
{
XmlNamespaceManager nsmgr = new XmlNamespaceManager(soapCreateReservationRq.NameTable);
nsmgr.AddNamespace("r", "http://soa.company.com/ReservationEnt");
nsmgr.AddNamespace("s", "http://www.w3.org/2003/05/soap-envelope");
XmlNodeList xmlNodeList = soapCreateReservationRq.SelectNodes("s:Envelope/s:Body/r:CreateReservationRq",nsmgr);
XmlNode xmlnode = xmlNodeList[0];
XmlSerializer serial = new XmlSerializer(typeof(ServiceReference1.CreateReservationRqType));
ServiceReference1.CreateReservationRqType rq = (ServiceReference1.CreateReservationRqType)serial.Deserialize(new XmlNodeReader(xmlnode));
}
As you can see in the next image the service that tries to consume your service uses a Request Method POST with the Accept-Encoding: gzip. That is why you can expose a Web API that can be consumed for a SOAP service.
Related
I have to prepare web service for iOS and Android applications. My platform will be .NET with C#. Now I am not sure which of the following is the best option to follow.
WCF SOAP XML Service
WCF SOAP JSON Service
WCF REST XML Service
WCF REST JSON Service
ASMX SOAP XML Service
ASMX SOAP JSON Service
ASMX REST XML Service
ASMX REST JSON Service
So far I have worked with only ASMX SOAP service and these are very easy to use and develop but I got some suggestion from iOS developers that JSON is good for their development. Some times they also suggested to prepare REST services but according to me they are less secure.
Please let me know which one of the above eight approach is best for small user base application and which one is best for large user base application.
Since iOS and Android doesn't have too much SOAP implementations available, a large number of developers (including me) are choosing REST based web services.
The are several reasons to choose for REST services over SOAP webservices, one of them is simplicity, REST webservices usually requires the implementation of HTTP requests plus the generation of request body in a plain JSON or XML.
SOAP requests only differs on its extra details about the resource being requested, these additional details/bytes, may become a problem while coding the request on client side and, of course, cause an overhead on transmission.
By implementing webservices over REST you can take advantage of two awesome libraries, for iOS you have Restkit, and on Android you can use restlet with jackson.
Based on what has been said above, I strongly suggest WCF REST XML Service or WCF REST JSON Service, where WCF REST JSON will be the most performatic option, since the serialization format (JSON) is much more efficient way to represent data to be transferred over network connection.
Take a look at ServiceStack:
Service Stack is a high-performance .NET web services platform that simplifies the development of high-performance REST (JSON, XML, JSV, HTML, MsgPack, ProtoBuf, CSV) and WCF SOAP Web Services.
What is the most current (.NET 4) way to send a raw XML request to a web service? Does it differ between asmx and wcf services?
I want to build XML via a front-end interface and have the ability to send it to different endpoints. These endpoints could be asmx or wcf. What is the best approach to get started doing this?
I think we mean the same thing; I usually prefer not just to send XML but to work with objects and let the WCF engine to decide in what format itll pass it to the service/client (which might depend on the protocls you and your service providers support). In the terms of WCF, it means defining classes as Data Contracts, and working with their instances only, and not the XML they might represent.
If the other side supports ASMX only, it limits the supported protocols WCF can use to work against to WS-I Basic Profile 1.1 (if Im not mistaken with this), but whatever technology You choose/work against, the concept, in my opinion, should remain the same: in .NET work with classes, and let the underlying communication technology to decide how to serialize and pass it to the other side. Of course, its also more secure than just to send raw string as xml (though you can probably solve some of the security issues by validating against a schema the received xml)
I have a web service written in C# using SOAP. A client has requested the same service be available as a REST based service.
Is there a clever/quick way I can achieve this, or am I looking at a rebuild from new?
SOAP based services are built with a completely different set of constraints than REST services. If the services is simple then the end result of the two approaches may look somewhat related, but in reality they are two completely different approaches.
SOAP and REST are different not only conceptually but mechanically.
Conceptually SOAP methods are pretty much RPC, remote procedures. So your web methods look like "GetListOfCustomers" and "DeleteCustomer". While in REST you model Customers as resources and use HTTP verbs on these resource. To get the list of customers client will send HTTP GET and server will return customer representation in XML, JSON, HTML or custom format. Customer representation may have embedded URL links that will allow client code to delete customer for example. This is called HATEOAS
Mechanically SOAP is a layer on top of HTTP. Layer that ignores and reimplements existing HTTP capabilities like envelop, verbs, caching, encoding etc. As opposed to REST that relies on all these HTTP features. So mechanically REST is simpler because there is no additional layer that SOAP has.
When you were asked to make existing SOAP service to be available as REST it probably implied purely mechanical aspects. You probably need "XML RPC over HTTP" which will require some work on your part but may not be as hard as redesigning API from SOAP/RPC to REST/HATEOAS.
The solution will depend on how you implemented the SOAP web service.
This is not a "conversion". You will be writing a REST-based service to do the same sorts of thing that your SOAP service does. If you developed your SOAP service correctly, then you will be able to reuse much of the code. You will then be able to deploy a single service that serves both requirements.
I've recently discovered a way to implement RESTful services using Global.asax (by handling the Application_BeginRequest event). Basically, I am saying it is possible (and easy) to implement a RESTful web service in classic ASP.NET, without any need for WCF.
It takes approximately 30 lines of code to figure out which method you want to call (from the URL) and pass it parameters (from the query string, via reflection) as well as serialize the result using XmlSerializer. It all leads to a web service that can be accessed through HTTP GET requests, and returns standard XML data.
So with that in mind, is there any reason to use WCF when creating a RESTful web service that will be invoked only through HTTP GET requests? WCF introduces a lot of overhead and restrictions, whereas the Global.asax approach I described above is much easier to implement, customize, and deploy.
Note - JSON endpoints can also be implemented without WCF by using the JavaScriptSerializer.
Also - HTTP POST requests can be handled by Global.asax in a similar way.
So in the end, what would be the reason to use WCF in such a case? Is there better scalability or performance?
You can also use Asp.Net MVC to implement REST quite easy.
What you don't get for free with this approach is:
non-HTTP bindings.
support for multiple message formats.
non-IIS hosting.
control over the process activation.
control over the instance creation.
object pooling.
message queueing.
transactions.
scalability and reliability.
additional technologies built on top of WCF like the OData support.
If none of these applies to your scenario - you don't need WCF.
The answer is, 2 different pipelines, but the WCF pipeline was built specifically for services, and ASP.Net was built for rendering content via HTTP. Both have their pluses and minuses.
If you are comfortable with the ASP.net stack, and don't have to worry about things like standards, then ASP.Net is fine.
But if you want the best of both worlds, try WCF Data Services, all the cool built-in features of WCF, with none of the hassles. Currently, MVC does not have a view engine to generate OData.
I am thinking to start writing some REST web services as a way to provide data. I guess that when my REST web services are available, then some of my web applications and console applications will be able to use REST web service as data service to get, add, update and delete data to databases. In addition to that, I would like to add authentication feature to identify any request.
My question is that where should I start? I saw Microsoft ADO.Net Data Services. Not sure if this is a good start place? Are there any examples available?
Check out the REST in WCF MSDN site and the starter kit. Good article here too.
You may also want to check out servicestack.net An Open Source, cross-platform, high-performance web service framework that lets you develop web services using code-first, strongly-typed DTO's which will automatically (without any configuration) be immediately available on a variety of different endpoints out-of-the-box (i.e. XML, JSON, JSV, SOAP 1.1/1.2).
REST, RPC and SOAP out of the box
In addition, your same web services can also be made available via any ReST-ful url of your choice where the preferred serialization format can be specified by your REST client i.e.
Using the HTTP Accept: header
Appending the preferred format to the query string e.g. ?format=xml
See the Nothing but REST! web service example for how to develop a complete REST-ful Ajax CRUD app with only 1 page of jQuery and 1 page of C#.
A good place to start is the Hello World example to see how to easily add ServiceStack web services to any existing ASP.NET web application.
Performance
For the performance conscience, ServiceStack makes an excellent Ajax server as it comes bundled with the fastest JSON Serializer for .NET (> 3x faster than other JSON Serializers).
Checkout this live Ajax app for a taste (Live demo hosted on Linux/Nginx/MONO).
Simple Northwind Example
ServiceStack also makes it easy to create strong-typed frictionless web services where with just the code below is all you need to return a List of Customer POCOs:
public class CustomersService : RestServiceBase<Customers>
{
public IDbConnectionFactory DbFactory { get; set; }
public override object OnGet(Customers request)
{
return new CustomersResponse { Customers = DbFactory.Exec(dbCmd =>
dbCmd.Select<Customer>())
};
}
With no other config, you can now call the above webservice REST-fully returning all of:
XML
JSON
CSV
HTML
JSV
SOAP
Accessing web services on the client
You can call the above web service re-using the same DTOs that your web services were defined with (i.e. no code-gen is required) using your preferred generic ServiceClient (i.e Json, Xml, etc). This allows you to call your web services using a strong-typed API with just 1 Line of code:
C# Sync Example
IServiceClient client = new JsonServiceClient("http://host/service");
var customers = client.Send<CustomersResponse>(new Customers());
And since your web services are also REST services, it works seamlessly with JavaScript ajax clients, e.g:
Using jQuery
$.getJSON("http://host/service", function(r) { alert(r.Customers.length); });
ASP.NET Web API is now the Microsoft framework for creating RESTful services.
http://www.asp.net/web-api
If you are new to REST in the .net world then start with OpenRasta. The other Microsoft solutions can do REST if you work hard at it but they will guide you down a route where you will most likely end up with POD(Plain old data) over HTTP. That is not what REST is all about. If that's all you want then that's cool too, but it is not REST.
If you're going WCF, the WCF REST Starter Kit that JP referred to is a great place to start.
Omar Al Zabir provides a pretty good example of using ASP.NET MVC to provide RESTful services that are fluent in both XML and JSON
You can also go the ADO.NET Data Services route you suggested. These services are built on top of the WCF stack.
I've never stumbled across any really good guidance on how to select between these options. In ASP.NET MVC you take on the majority of the plumbing burden but also have maximal control. Straight RESTful WCF is the happy middle ground although WCF tends to want to have things done its way. ADO.NET Data Services are pretty magical with the downside of buying fully into a given approach to generating these services and losing more flexibility.
There are a couple of good books you can read on the topic of RESTful services with .NET. Both O'Reilly and Microsoft Press have recently released books on this topic. Perhaps the most important advice I can provide you is to consume and understand several open RESTful services (e.g. Twitter, Amazon, Flickr) to understand the design decisions that went into creating the services. User provisioning, authentication mechanism, and supported content types (e.g. JSON, XML, RSS/ATOM) are some of the decisions that you can observe in action to aid you in your path to creating your service API.