How do I consume a RESTful web service in C# code?
NOTE: by RESTful, I mean non-SOAP. For example, in the flickr API you can call their web service as follows to return JSON data:
http://api.flickr.com/services/feeds/photos_public.gne?tags=cats&tagmode=any&format=json
Do I simply use HttpWebRequest?
What if I'm using a web service that takes POST parameters? Would that use HttpWebRequest also?
Is there any benefit to using WCF on the consumer side?
WCF provides a unified programming model for communication, so if you later decide that you do not want to use REST or you want to provide an extra type of endpoint for example SOAP, you only need tp change the configuration.
Take a look at REST for WCF:
http://msdn.microsoft.com/en-us/netframework/cc950529.aspx
Their is a demonstration and labs in the .NET Framework 3.5 Enhancements Training Kit, which provides two labs based around creating, servicing and consuming RESTFul services. The above link is the best MS combined resources of REST services.
Bob.
Related
Description:
I have an client app consuming a WCF service, both runing on .NET Core and hosted as web apps in Azure.
The client has access to an interface that the service implements as its DataContract.
Currently I consume the service via creating a ChannelFactory based on an DataContract of the WCF service.
Because lots of reasons I'd like to move away from WCF.
My first idea was to convert the WCF service to a Web API and implement something like OpenAPI (Swagger) and from there consume the API via generated docs.
However I can't really find anything similar to the way you would consume a WCF contract and then be able to call upon its methods.
Question:
Is it possible o use a shared interface between the consumer and a Web API in a way that enables me to call upon the methods (routes) in that interface? Be it using OpenAPI (Swagger) or any other framework/lib/or otherwise.
Please let me know if anything is unclear and I'll add info, I'm aware its a somewhat broad question.
Initially when I built an application, there was only a requirement to expose an endpoint using WCF. Now, there is a requirement to expose another endpoint using REST therefore I have used .Net Web Api to do so. The WCF endpoint is hosted in a Windows service therefore I have hosted the Web Api endpoint in the same service. Are there any issues in doing so? Any performance considerations? After some exhaustive searching, I couldn't find any substancial information on the topic.
Are there any issues in doing so?
It may be better to expose the rest API via WCF using webHttpBinding rather than introduce WebAPI into the mix. I'm not aware of any problems this would cause per se, but in terms of solution simplicity I think it makes more sense to take advantage of WCF's multiple-endpoints-to-one-service-contract mapping capability.
I did consider this but I've read a lot of bad reviews about using WCF
to expose RESTful endpoints. Moreover, it appears Web Api is the
preferred technology as mentioned here:
WCF vs ASP.NET Web API
Agreed. If you were starting from scratch then I wouldn't hesitate recommending WebAPI over WCF (actually I would recommend using Nancyfx over WebApi any day of the week).
You can expose your service as HTTP with about 10 minutes work using WCF, assuming you wish to expose the same operations as are currently defined on your service contract, as you have already have the soap endpoint.
Plus you will end up with a simpler solution without the considerable bloat of asp.net/owin.
What is the best way to create WebService using Visual Studio which can be consumed by PHP or Java client?
The WebService must require authorization.
I have some expierence in creation of WCF Service with custom authentication (see: http://jaliyaudagedara.blogspot.com/2013/07/set-wcf-service-authentication-to-use.html )
and I know that PHP programmers have problems to pass credentials.
Are there any methods of protection of WebService that are compatible with PHP world?
WEB API 2 Is Microsoft's Latest technology for Hosting Web Services.
It is compatible with all official Standards. (XML, JSON, REST ) etc.
There is no reason any platform to have any difficulties connecting to such an API.
You can pass data for identification just by initiating a POST request with a JSON Object.
I'm looking for the difference summary between ASP.NET MVC Web API and WCF Service.
I've seen this question What is the difference between Asp.Net Web API and WCF Service?
and this question WCF vs ASP.NET Web API too, but they don't summarize what I can achieve with the one, what I cannot achieve with the other.
Both can be contacted via url, I first thought that was a difference between them.
So in short:
What can I do with WCF what I cannot do with ASP.NET Web API and visa versa?
this list is by no means exhaustive.
Things WCF does that you cannot do (with ease) using Web API.
Supports SOAP based XML format.
Supports strongly typed data contracts.
Supports a single point of metadata information exchange using WSDL etc.
Supports varied bindings like TCP, Named Pipes, MSMQ, even UDP etc.
Supports varied hosting options like console apps, WAS, IIS, Windows Services.
Supports one way messaging, duplex, message queues out of the box.
Supports multiple authentication schemes like Windows, Forms, Certificates etc.
Things Web API does that you cannot do (with ease) using WCF.
Supports the full features of HTTP. (Uri based access, Http Requests/Response, Http Caching etc.) To do this in WCF you need to additional work to configure it as REST service etc.
Is Lightweight with minimal configuration.
Supports the Routing, Controller/Action MVC paradigm, Model Binding etc.
Basically Web API is an easy way to do RESTful services over Http without knowing much about Web services.
To do the same in WCF, you need to do additional work in terms of httpBindings, UriTemplates, Verbs etc. And that means, understanding WCF first. And then using WCF to implement a RESTFul service over http, which is what Web Api provides out of the box.
This is not a summary per se. Its a sort of practical guide I hope.
For me it ultimately boils down to how simple I want my front-end application code to look like, and also something to do with how to achieve maximum productivity.
Traditional WCF over http is SOAP based messaging protocol. You add a service reference in your project, and Visual Studio takes care of generating the proxy classes. And you work with the instance of the proxy classes. So when you are writing your front-end code, you have intellisense to help you. Don't be fooled. This is just the IDE making life simpler for you. Underneath its pretty complicated. But my productivity is boosted to a degree. I don't have to write proxy classes. Hence, this is what I'd opt for a c# based front-end.
Alternatively, if I had to deal with a Webapi endpoint, I do not have the luxury of any IDE generated proxy classes. Therefore I'd have write code for everything. Typically I use the HttpClient classes to talk to my web api end points. Hypothetically, I could write a proxy classes to talk to web api. But it isn't as simple as in your wcf case where they were auto-generated for you.
On another line or reasoning, if my front-end was JavaScript, then my only best bet is have the web service hosted over web api, rather than wcf. If I were to talk to wcf endpoints from Js, that would be a PITN.
So it ultimately rests on your product plan, design, project schedules, etc software development plan. All the best.
Please forgive me for this basic and a little theoretical question as I dont know much about web services.
I m not refering WCF service, I am reffering simple service in .net / C#. I want to know how to know is it soap or rest service ?
How we can change this type from Soap to Rest and vice versa ?
Thanks
XML Web Services (aka classic/legacy ASMX web services) should not be used for active development. If you must, there is a nice walkthrough on MSDN for adding Web references in more recent versions of Visual Studio (> 2005).
On the other hand, if your web service is truly Restful then you won't be able to create the equivalent of a service reference to it. You'll need to either use the HttpWebRequest, WebClient, or the new HttpClient from .NET 4.5 (also available from the Rest starter kit which is depreciated as well).
As an alternative if you are looking to implement a client that is able to handle both situations, I would recommend HttpWebRequest to POST to the SOAP (non-WCF) service. The problem with this method is you'll likely have to wrap the request in the SOAP wrapper yourself. Luckily there are examples of doing so on the net that you can at least use as a starting point.
ASMX services are build upon SOAP. REST is simply a HTTP based, You can access(or call) your business resources the way you access the normal URLs.
For ex in products catalog system, by using asmx you create set of functions to add,update,delete products. like addProduct(),updateProduct, etc..
But in REST, you will be having single point of access, like http:\mysystem\prodcuts. To retrieve,add,update,delete products, you will be using respective HTTP verbs (GET,POST,PUT,DELETE) on the same URL.
so,technically it's not possible to convert asmx(SOAP) service to rest...