I want to host on the same website WebApi endpoints (RESTfull off course) and WCF endpoints (SOAP). I know it can be done if you do it all in WCF.
The question is - can i mix both technologies in the same website?
Thanks!
You can have both technologies under same website, provided there are in different virtual directory. For example you can place your api under "~/api" and your WCF service in "~/service". In such a case, both can co-exists.
Related
I have experience in developing Restful web service using WCF. For the next project, I am considering Web API because that is the latest technology.
During my search, I found that an important reason for Web API recommendation is that it is Restful and can be accessed by HTTP protocol.
But we can also use WCF to create a restful web service that can be consumed even by mobile devices. I understand that to create a restful service using WCF, there is extra configuration involved, but besides that are there any other reasons for preferring Web API over WCF?
In other words, does Web API provide an exact subset of WCF functionality, or is there something you can do with Web API that you cannot do with a WCF service exposed as restful?
I have a RESTFul WCF service and it needs to be deployed now. I am really confused whether to deploy in windows service or IIS 7. I need to implement SSL also so the protocol would be HTTPS. It is just a simple service consumed by client using HTTPS protocol.
Please let me know which one is better.
Your question seems to have been asked (and answered) previously.
The following link provides a good discussion:
IIS WCF service hosting vs Windows Service
If your RESTFul WCF Service needs to be accessed via http (or https) protocol, then deploy in IIS7.
I'm newbie in WCF. I have some questions need to be answered.
Can I use WCF to make a simple chat application from a client to a client (via WCF Service) ?
I have tried follow many examples, And i got a problem. I don't think that IIS need to be installed when i using WCF Selft Hosted, right ?
Sorry about my English !
You don't need IIS for self-hosted WCF services. Look at the ServiceHost class.
Yes, you can make a chat application (client to client) using a service "in the middle". The clients would have to register with the service and then a callback contract should do the job.
I've been looking into the possibility of using ASP.NET Web API and SignalR in a self-hosted application, and I noticed that the ASP.NET Web API self-hosted implementation uses WCF, and the SignalR self-hosted implementation uses System.Net.HttpListener. This makes it a little harder to come up with a combined self-hosting solution, but it does get me wondering why the different project teams would use different approaches.
What are the advantages and disadvantages of each approach? Is there any particular reason why SignalR could not use WCF self-hosting, or Web API could not use HttpListener?
EDIT: I understand that Web API self-hosting provides a more complete stack than SignalR, my question is more about why you would choose a WCF implementation over System.Net.HttpListener when implementing your own self-hosting solution.
Web API self host provides entire HTTP stack so it's much much richer than System.Net.HttpListener.
SignalR uses that to purely open a communication window for its own purposes.
So yeah for now, you need to run them in parallel on different ports.
In the future, with OWIN, you will have everything under one roof.
EDIT: there was actually an issue similar to yours raised on SignalR github, and the answer was pretty much what I just said - https://github.com/SignalR/SignalR/issues/277
Just so we are on the same page, The WCF Self-host that Web API Self host uses, does use HttpListener under the covers. However, I think I may have found a major downside to the WCF Self-host.
I have not confirmed this yet, but it seems that when you use Web API Self Host, the base address you provide is not translated directly into a HttpListener prefix. It seems like WCF translates the base address and wildcards the host.
This means that the WCF self-host will respond to any host on the specified port. This means that you cannot run a Web API Self hosted service side by side with IIS on the same port using a different host name.
This might be the reason that SignalR decided to scrap the WCF Self-Host and use HTTPListener directly.
While you can use the WCF stack to host the services yourself, you may want to consider the "IIS 7.0 Hostable Web Core". It has the benefit of running IIS in your user process. Using this approach, you can have several applications running on the same port, irrespective of the technologies.
If you are interested, you can look at:
Host your own Web Server in your application using IIS 7.0 Hostable Web Core
Creating Hosted Web Core Applications
This all assumes you are running Vista or later...
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!!!