I'm not even sure how to express this question which is likely why my normal google-Fu failed me. So here goes. Visual studio has several project templates that the generic host. There is the worker service for console applications, webhost for asp.net and an template for grpc.
All those hosts somehow translate a request over a certain protocol to actions in the application. Webhost uses Http as a communications layer, grpc uses grpc. NServicesBus uses messagequeue's.
I'm trying to find examples of what is needed to implement a custom "protocol mapper" Does anyone know of any example to do this? Or basic documentation on what would need to be implemented.
Basically what is behind functions like ConfigureWebhostDefaults or UseNServiceBus for NServiceBus etc etc.. Soemthing that listens for network calls or other events and then fires up the correct function in the correct controllers to use MVC terms.
This is not the clearest question I have asked, but it does not help if one does not know how the thing you are looking for is named.
I have read many articles in the web so far, about the differences between WCF and ASP.Net web API. Unfortunately I could not come up to a clear idea about what will serve my purpose. Most of the Articles I have read highlighted on the design point of view of the two web services. But I am confused what will work best for my project and why? Here is my brief description of the project.
I need to create a communication channel between two servers (both are written in C#). The servers will communicate using messages (certain type of commands). The messages sometimes can be only acknowledgements, and sometimes the messages may contain instructions to do some computation. For example, one message can be draw something, or send an SMS etc. And not necessarily the messages will involve any database transactions. But the messages can sometimes send large text files as payload (around 1-5 MB maxm). What I believe WCF is very will surely do this, but can I do the same with ASP.net web API. Because so far all the example I have seen for ASP.Net web api: they are good for RESTful services that manipulate some kind of DB store (GET, PUT, DELETE). But in my case I will need to expose service points that will
do some kind of processing such as return the value of a computation, sending and acknowledging messages, etc.
Not just manipulating a DB-store.
So, what should be the best and simplest way to do so? It is needed to be mentioned that I did not find any straight forward example of achieving this using ASP.Net web API.
The Question you have asked is an overly-broad or primarily opinion-based, and its hard to give an example for what you have asked.
Important Points:
Firstly, if you are going to create a service which would be used on different platforms, then go with WCF.
Secondly, if you are creating internet service which is going to use external resource, then go with Web API.
Web API is the best choice if you are going to create a service for low bandwidth devices or mobile devices to access client.HTTP
request/response is also more readable as compared to SOAP because it
contains header, body, etc. which makes it complex.
Just take few minutes and read the below article, until you get complete understanding of few principles.
Original Source Can be found Here, Here and Here.
To whom choose between WCF or WEB API :
Choose WCF when you want to create a service that should support special scenarios such as one way messaging, message queues, duplex communication etc.
Choose WCF when you want to create a service that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transport channels are unavailable.
Choose Web API when you want to create a resource-oriented services over HTTP that can use the full features of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
Choose Web API when you want to expose your service to a broad range of clients including browsers, mobiles, iphone and tablets.
Why to choose Web API
Web API doesn't have tedious and extensive configuration like WCF REST service.
It is very simple, creating service with Web API. Where as With WCF REST, service creation is bit difficult (requires clear understanding of configurations).
Web API is only based on HTTP and HTTPS and easy to define, expose and consume in a REST-full way.
Web API is light weight architecture and good for devices which have limited bandwidth like smart phones.
My Opinion:
Simplest way to do so - Web API (Since you dont have any examples for this)
Hardest Way is (Configurations) - WCF (Better go with WCF, since you have examples)
I hope this gives you a clear idea about what to choose...
First things first, RESTful is a stateless and uniform interface norm that can be applied to web services. It doesn't have to be automatically and only plain old CRUD service backed by a DB.
In the real world, we can hardly say that all web REST API respect fully the norm, in fact they don't most of the time, especially the stateless part.
For your message based API, especially if it's bidirectional and event based, you can use websockets and consider the REST API a way to expose an uniform, stateless web interface to create those. And yes you can use websockets with ASP.NET WebApi there's plenty of tutorial out there, even for the newer ASP.NET Core.
The "between services" interactions part is no different than the usual Web browser <=> Web service, you're just using C# code instead of JS for the client.
I can hardly recommend WCF that uses SOAP since it's hardly portable considering the web standards nowadays. For instance if want to use a browser client instead of another ASP.NET service, well you'll have to do additional code client side to handle supports.
You can use WCF websockets, providing the almost all the advantages of WCF SOAP.
tl;dr :
You can mix RESTful and Websockets, it can actually be better than going full REST or full Websockets
It's personal preference to use SOAP over websockets but do comes with a potential technical debt considering what you want to do afterwards
Message API between services is no different than a message API between a service and a browser
WebAPI is not just good for RESTful webservices. You can easily send requests to a WebAPI controller and handle it the way you want : calculations, sending messages, interact with a CRM, interact with DB or anything else.
WCF was created to manage SOAP based webservices and brings extra complexity. It handles TCP, Mime...
If you just need to handle HTTP requests, the simplest way is to go with WebAPI.
I would suggest Web API if it is for RESTful services as WCF was never made to serve as Restful services although you can serve as one where as Web API was made particularly for this.
I'm currently devoloping a N-Tier Application with C# as Business Tier. It's a kind of ERP and I need authentication (email/password) for this app.
I need also permissions based on the login (create orders, delete articles)
All this informations should be stored in one database.
As UI Clients I planned to make WPF Client, ASP.Net and maybe in future iPhone/Android.
As message broker I use RabbitMQ (Clients talk to Business Layer only over AMQP. Due to the advanteges I have more than one Business Layer for round robin dispatching).
On my research for authentication in N-Tier applications I found one advise for Windows Identity Foundation. WIF is completly new for me. All the examples I found handle only ASP.Net Applications.
My question now is:
Is WIF the right thing for me or should I implement this session handling on my own?
If WIF can fit my needs, what is the best way to handle this?
Do I have to implement a custom STS and place it within a WCF Service?
As you are explicitly mentioning RabbitMq, I am suggesting ServiceStack for your service interface.
One issue with MQs in general is that they are decoupled from any meta information, such as HTTP Headers, to inject authentication. You should in contrast provide a property Session (with pre authentication) or UserName and Password in your message (where the later one is not prefered, as the credentials are passed in plain). A sample solution with the built-in SessionFeature of ServiceStack is available in their documentation.
Another nice feature of ServiceStack is that you can decorate your handlers not only with AuthenticateAttribute but also with RequiredRoleAttribute and RequiredPermissionAttribute.
Also: How do you plan to queue a message with Android? Can you expose the internal MQ to the outside, and is there a client available for eg Android? Therefore I suggest a dual endpoint over HTTP to queue messages in whatever MQ you choose to use. More information on how to integrate MQ in your HTTP service is available in the documentation.
With ServiceStack you can spin as many consumer instances you want, as there is a plain communication without all the serivce stuff available.
Trivia: As I am authoring an upcoming book on Mastering ServiceStack I am a little bit biased. Nevertheless I do cover most of your questions in the book, and provide code examples: Bits and pieces to your scenario are already covered here (do not get frightened by specific MQ, they are interchangeable).
I've built a REST API using web api 2 for handling the CRUD of my grid, this works fine. I'm trying to now implement SignalR for real time updates (doing something similar as described here Can I incorporate both SignalR and a RESTful API?) and it would appear that you MUST use the hubs for all server side operations when using a Kendo DataSource. I've been searching for some kind of example or documentation that allows for you to possibly use a REST API for CRUD but still allow the client to subscribe to a hub that will push data in real time when something happens with the data.
My question - Is this possible with the Kendo DataSource and if so how?
I am following the documentation here http://docs.telerik.com/kendo-ui/api/javascript/data/datasource#configuration-transport.signalr for configuring SignalR on the client. Basically though what I would like to do is override the transport.signalr.server configs so that it keep talking to my REST API and just let the client subscribe to the hub so it can receive data in real time. Kendo's documentation is so sparse I can't tell if this is just not possible or if I'm missing something however.
I come from a RubyOnRails background so sorry if this looks like a silly question:
Let's say we are creating our app in ASP.NET MVC and we need to develop some RESTful web services to give us some JSON that we can use in our app.
How do you create those services? Is it WCF ?
In Ruby we actually used Java-Jersey for the service side but in my current work place it is a .NET shop with strong experience in Silverlight and RIA Services. so what is the NET approach of web services for ASP.NET MVC ?
WCF is a super powerful but incredibly complex communication framework that allows systems to talk over multiple protocols. It sounded cool during Microsoft's initial pitch, but there is an incredible amount of overhead just to, say, push a scalar across the wire. WCF certainly still has its place, but it's a beast of a framework.
Given how much effort there is in integrating it into a solution, some MVC developers noticed that, Hey! I can just return a JsonResult from my MVC controller and have my AJAX scripts consume that. Quick and dirty!
Microsoft then refined the experience with Web API, which is focused solely on developing HTTP services. It's architected quite similarly with MVC, which makes it pretty darned easy to pick up. It is typically RESTful, but doesn't need to be. By design it works really, really well with HTTP - remember, HTTP is an application protocol as well as a transport protocol.
There is also neat stuff like how it takes care of serialization for you - if the client wants XML, Web API gives it XML. If the client wants JSON, Web API gives it JSON. With a little work, you can even come up with custom serialization formats!
So, before I go off on one of the many tangents about how awesome sauce Web API is, let me say that if you are looking for a simple, powerful framework that can deliver RESTful services over HTTP, then Web API is your solution.
http://www.asp.net/web-api