i have a requirement to convert different kinds of services like soap based services, wcf xml services,web services that is currently running in silverlight app. so conversion we have use angular as front end and server side currently don't do a modification.
In this case, question have is
is it possible to consume different structures of xml services like soap, asmx ,web services in angular directly. or need to deserialize in angular.
Note : currently we don't modify existing services responses,because the client already using existing app.for time consumption,have only change the business logic in angular.
Or else we need to write any webapi or wrapper to consume the service and to convert to json and host it in server to consume json,
is there any other techniques ? suggestions are more appreciated
Ideally, this should be handle at the server - by simply adding a new endpoint should do the work.
However, if your ask is not to change anything on server, below are the npm packages you can utilize.
node-xml2js
ngx-xml2json
More reference:
Angular2: Convert XML to JSON
Angular: Convert XML to JSON
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.
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.
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 am creating a few basic web services using c#, and I am trying to have the web service return back just a normal name=value&name=value without any kind of xml or json format. The legacy system hitting these services is fairly old and doesn't support xml or json. Is doing this possible?
If the legacy service that's targeting this web service is that old, how exactly are you calling the web service from it? It may be easier to create an .aspx page (or even better, .ashx) that parses the request and makes the response simply using Response.Write.
If you update your question/add a comment with the detail about how you're calling the service, I'll update my answer accordingly =)
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.