We want to use Web API for inter-operable purposes. i mean our web api can be exposed and used in different type of apps ( Asp.net mvc, php, android, windows store/phone and ios).
We are not using wcf and prefer web api. Will it be a good choice ? we just need http and https.
Please guide the best.
if you only need support http protocol yes, web api is an excellent option, web api has a lot of features that can help you to build robust http services, and yes, I mean is a good choice.
be careful when you build yours web api service, use best practices, security in your service, and think in rest architecture, not only simple web services and you will have a true rest service
If you want to read more about this (to have a good base, not the final or only way to do this), see the rest maturity model and json api.
WCF is the best way when you need to support others protocols that only http.
Regards
Related
I read bunch of articles about SOAP and REST(WCF and Web API).
And after all the reading I end up with understanding that WCF is more powerful, but lots of it's functionality can be implemented in Web API. For example for duplex communication in web API we can use SignalR or sockets. WCF gives you more security with WS-Security, but in Web API you can use HTTPs
So what can WCF give you that Web API cant, except working with lots of different protocols and data formats?
WCF supports more protocols and transports than Web Api, some of then very useful, like SOAP, FTP and MSMQ.
Here you have a table comparing both: https://msdn.microsoft.com/en-us/library/jj823172.aspx
Both has their own purposes, and the table above can help you to choose.
Both of them are using for different scenario WebApi uses full features of Restful services like Uri caching and various other features .Check the below difference I hope it will help you
I know, there are 1000x topics about WCF and security - seems to be a hot topic. I still want to get some up-to-date opinions about this.
I am creating a Webservice (free to use) where clients can register on my website, get a secure token, and can consume the webservice with this token. Consuming the webservice must be very simple independent from what language the client is using (PHP,Java,.NET).
Also I need to have one webservice-call exposed for use in Windows Phone 7.1, Android, iOS.
I've currently implemented the Service in WCF using wsHttpBinding and TransportWithMessageCredential security. Now I have already compatibilty issues trying to consume with WP7...
What, in your opinion would be the best Webservice/Security Framework for my needs?
* REST
* SOAP (With SoapHeaderAuthentication)
* etc...
Any feedback highly appreciated!
Thanks!
If it has to be consumed easily by different frameworks and devices, I would build a Rest service. Take a look at ASP.NET Web API.
You can use Web Api to return Json, which can be easily consumed by Windows Phone 7 apps, Java, php, whatever. You have the possibility to implement https and authentication.
Keep in mind that it's still in a Beta stage and that you'll have some issues accessing it cross domain, but it's a problem that can be overcome. I guess this will be made easy before it hits RTM.
Rest is easier with interoperability. If you do use soap then basicHttpBinding is much better than wsHttpBinding since the latter has some proprietary protocols.
What are the pros and cons of using each technology?
WCF Web Api is now merged into Asp.net
Asp.net web api now supports self hosting.
I still imagine if I want to expose multiple protocol schemas for the same operation I would still lean towards WCF or can Mvc end point do this too?
Also does the new Asp.Net web api expose Wsdl? If not how would the client figure out what operation is available to them?
Arguably the best feature of Mvc is the modelbinder. How robust is the WCF equivalent?
So can someone tell me what advantage does the Asp.net web api bring to the table? WCF seems overwhelmingly the more powerful/scalable choice, imo. About the only thing the Mvc Web Api has over the WCF model is probably ease of development, but that means squat if it ends up being a serious design limitation down the road.
First, I suggest you read my post on the subject:
http://blogs.microsoft.co.il/blogs/idof/archive/2012/03/05/wcf-or-asp-net-web-apis-my-two-cents-on-the-subject.aspx
Regarding your WSDL question - since the WebApi does not use SOAP, it does not require a WSDL, and does not export one. You can use Hypermedia to return resources with a list of possible activity URLs (think of it as a self-describing resource)
The choice depends on what we want to do.
ASP.NET Web API is a framework for building non-SOAP based services over HTTP only - so there aren't more transport protocols available using this framework.
WCF / Windows Communication Foundation is a framework for exchanging SOAP-based messages - here we use a lot of transport protocols: HTTP, TCP, Named pipes, MSMQ, etc...
I am not sure about which one has better performance regarding the amount of data, maybe WCF since we can use low protocols. Any comments are appreciated.
The WCF Web API primarily focuses on REST implementations. If you are setting up a REST implementation, the standard WCF bits are a bit of a pain in the rear. If you are setting up RESTful services, you will find the WCF Web API a much nicer experience. If you are setting up SOAP services, then the WCF Web API is not your best friend, and you are better off using WCF for your services.
Use WCF for intranet/B2B sites n Web API for B2C/C2C/internet sites...SOAP/XML is still the standard for intra-businesses communication n it's not going to go away!!!
I want to learn doing RESTful webservices. I have surfed the web some hours and think that I have a good overview over what RESTful services are and now want to build my first service-application. I have a good small project that seems perfectly suited for doing it with a RESTful webservice.
I have seen that WCF has the ability to build RESTful webservices. My question is, if it is reasonable and efficient to write RESTful webservices with WCF or if there are better suited alternatives for writing such services in the Microsoft programing environment.
(As additional information, I already have experience in using WCF, but more in using it in a RPC-way. But I don't think that this is important for my question anyway).
WCF supports RESTful services via the webHttpBinding. This works but doesn't give you alot of control for working with the HTTP protocol itself (although some things got better in 4.0)
The next version is going to have a lot more support for RESTful services. The team are being very open about the new Web API so if you are not about to put something into production then I'd start with the new API
WCF is perfectly valid and very capable of handling REST services - you won't go wrong with that!
And there are a couple of alternatives out there, too - check them out and see which one suits your needs best:
RestSharp
OpenRasta
RestDotNet (clients only)
and probably quite a few more....
I'm new to WCF RESTFull services developpment and I'm looking for some usefull information and your experience feedback about using webHttpBinding compared to the new WCF Web API http://wcf.codeplex.com/.
What I'm looking for is to know about the shortcomings of webHttpBinding and therefore why to use the new Web api and especially what problems the new API resolves.
If you could point me to some blog posts comparing both of them or just talking about the problems when using webHttpBinding I would appreciate. Thank you in advance.
Main shortcomings I would say is that the webhttpbinding makes it difficult to handle HTTP specific concerns. It works great if all you are doing is passing an object over HTTP that is serialized into XML or JSON and which may be transported over different formats.
HTTP is much more than a simple transport protocol for XML and JSON, it is an application layer protocol with rich semantics. Web API is specifically targetting folks that want to build systems over HTTP that fully levergage HTTP's richness.
Web API embraces that HTTP Resources can have a multitude of representations based on the needs of different clients. One end of the spectrum could be a dumb browser that just talks to a service using a Form url encoded post and a GET, while the other end could be a more rich client that uses Atom/OData or a hypermedia based media type.
Web API embraces that there are other HTTP specific concerns like conneg, etags, etc which allow better leveraging intermediary web servers.
Web API is designed with more testability in mind, thus you can address working with HTTP messages or other concerns in a more testable manner.
Web API has a more simplified configuration story.
You can read more about the rationale here: http://blogs.msdn.com/b/endpoint/archive/2010/11/01/wcf-web-apis-http-your-way.aspx
The most significant difference for me is the change in programming model. You no longer write 'services' which expose 'operations' bound to HTTP idioms (GET, POST etc.). With Web APIs you create 'resources' (POCOs) with which your clients can interact.
Web APIs seem to be better at handling various custom media types (like PNG images for example).
Last but not least, Web APIs are far better suited for automated testing. For instance, you no longer have to use static context classes to access HTTP concepts such as response codes. You use POCO request and response classes which can be easily instantiated in automated tests using old-style new() operator.
I agree with Ladislav that Web APIs are just a preview now and building application on top of it can be both risky and forbidden by the means of license agreement (but I haven't checked that).
Have you considered #serialseb's OpenRasta? It is stable and offers very nice programming model for building RESTful services.
The Web API is something like possible future of REST development in WCF. It is just preview which can significantly change before final release (probably in next version of .NET framework). So if you want to build production REST service you should use webHttpBinding.
Available information about Web Api can be found for example on .NET Connected Framework team's blog and on the site you mentioned. It is simplification and extension of current REST API.
Web API provides a REST-friendly HTTP based API. Web API uses the patterns of MVC and is going to be very familiar to ASP.NET MVC developers. Web API can leverage the capabilities of HTTP as an application layer protocol, returning resources in multiple representations (XML, JSON, HTML etc.) according the the client's request headers.
On the other hand WCF webHttpBinding uses the patterns of WCF, and is going to appeal more to the WCF developer - ServiceContracts, OperationContracts, comprehensive (or overweight, depending how you look at it, config file), ability to self-host outside of IIS.
One of the things I like about Web API is the ability to use dynamic types to escape the constraints of the type system. I also like the default exception behavior in Web API - contrast WCF webHttpBinding where, by default, exceptions bubble up as HTTP 500 + an HTML payload (yuk!).
Its nice to have the choice between two excellent technologies here. I wouldn't describe Web API as 'newer' or 'better' that WCF, as this implies its a replacement technology and that WCF webHttpBinding is legacy, which I don't believe is true.
I chose to use WCF webHttpBinding recently to expose a JSON API for an existing WCF SOAP service. I believe it was a good choice because it fitted that style of that existing solution and minimized the amount of change required.