I need a simple approach to access a 3rd party SOAP Webservice from a MVC3/C# web application. I had hoped to use RestSharp, but I think this will only deal with RESTful Webservices.
The information I have on their API is currently:
"SOAP & JSON based APIs", and their examples are PHP/SOAP examples.
Related
I have a MVC web application and I make some ajax calls from the client to get back json data. Right now I just use MVC Action methods to return this data. I was wondering if I should be using the ASP.Net Web Api for these.
I understand that if I was building a REST solution I should be using it.
But in this case would it be justified to add the extra complexity? Is there any speed gain? I don't really need the Content Negotiation feature or the OData Support.
According to the post here (and the benchmark it references), Web API is a bit faster. Web api performance?
ASP.net Web api support both JSON and xml. Web Api is for implement rest web service on top of MVC application. It would add extra complexity for the application but you implement web api related method in separate controller.
Rest web services are usually faster than Normal SOAP web services.
In your case if your clients are just a web client no need to implement web services. But If you need to share service for different client (widows applications, windows services, third party applications) implement rest service using web API
I developed a website in ASP.NET MVC 4 using NHibernate, now I need to perform an integration with the site using Windows Forms.
How can I perform authentication system using the same users?
What technology should I use? Web API, SOAP or Rest?
Thanks!
Small clarification of terms : REST is an architectural style, SOAP is a protocol for exchanging information, and Web API is a framework to build HTTP Services.
The stock answer for questions like this is "It depends"
Before you continue with a technology selection, currently is your method for authenticating users separated properly from your business/presentation logic?
If that is the case, being that you are using MVC 4, Web API may be the path of least resistance, you can put all of the functionality that requires authentication behind Web API calls. And your controllers will call them. Once that is done, a Windows forms app can consume the data in a similar way.
I saw that ASP.Net MVC4 WebApi exposes services as a Rest ones.
But what is actually the difference between normal Rest and ASP.Net MVC4 WebApi?
I'm not sure what you mean by normal Rest.
REST is a paradigm.
HTTP is a protocol that follows that paradigm.
ASP.NET Web API allows developers to write ASP.NET applications that can be accessed via HTTP and adhere to the REST paradigm. While you could create a REST API without Web API, Web API provides a ton of features that will remove a lot of the pain associated with creating a truly RESTful API in ASP.NET.
apigee has many great resources for REST API best practicies.
Are you asking about the general REST standard or the way that REST has been done traditionally on the Microsoft platform prior to the MVC4 Web API? I am thinking you are approaching this as the second one.
The updated approach in MVC4 gives you more REST capabilities without the WCF model. Here is a recent post on the subject: http://mattmilner.com/Milner/Blog/post/2012/02/28/WebAPI-or-WCF.aspx.
Since REST services do not require XML, but we can use it with XML so can I call it a XML web service?
I'm doing my home work with the requirement that:
Using ASP.NET MVC
Provide an XML Web service
I was thinking about SOAP, but REST is more simple for me and I found alot of tut for REST with ASP.NET MVC rather than SOAP (They now all telling me about WCF...)
If REST is not an XML web service, please show some basic document about SOAP (or any thing else that call XML web service) with ASP.NET MVC!
Take a look at WCF Web Api. REST does not imply any particular format. A good REST service will allow you to set the Accept Header: json, xml, so on. E.g.: "accept" : "application/json"
Here is a good post on how to achieve this with WCF Web Api.
You can simply add a Web Service into your MVC application. You must take care about exclude "*.asmx" from your routes.
I.E:
routes.IgnoreRoute("{resource}.asmx/{*pathInfo}");
What is the difference between making calls to mvc controller methods and WCF WEB API Rest Service Calls?
I can create an mvc controller post method that will allow me to execute any code i need.
I can also create a WCF Web API REST Service with MVC.
What is the difference between these two approaches to accessing data ?
More specifically what are the advantages of utilizing WCF in this scenario ?
WCF Web API handles XML and JSON out of the box whereas you'll have to create your XML and JSON "by hand" (read: using the Serializers) when using MVC - this is only one of the benefits of WCF Web API over MVC.
Another one is the level of separation WCF Web API offers e.g. implementing your service logic vs. content negotiation.
Yet you can easily use IoC containers and unit test your APIs being created using WCF Web API.
WCF Web API mainly has been created to build ReSTful API's whereas MVC just allows it to create them too - thus with WCF Web API you'll feel more comfortable creating ReST APIs.
If you're planning to start a project from scratch as an Web (ReST) Api, you should start with WCF Web API.
If you're planning to start with a Website that also offers ReSTful Services, you should suggest MVC.
You should also regard this tweet from Glenn Block.
You could accomplish a typical REST API with either one.
Usually the issue boils down to (1) what specific features you need and (2) what technology you are more familiar with.
There are some features of WCF that are really neat and not available in MVC (like binary serializations, the ability to host without IIS, et cetera) but those are not typically requirements in a REST API.
Overall I would say:
If you have an WCF implementation already in place and want to expose it as a REST API go for it with WCF.
If you already have an MVC site and want to expose it as a REST API stick with MVC.