I have a web service; let's say that this web service does many calculations, it consumes a lot of memory resources. If my web services is call by 2 different clients, then the server will consume twice the resources. is it possible to limit my service to being used by one client, but not by using user authentication?
One idea that I have is to know when the service is being consumed, so if another user wants to use the service, it will receive a message that the service is been used by another user.
I know that one of the major goals of web services is to allow many users, and limiting the concurrent users is not a good idea. I am just curious if it is possible and how to do it, where can i find the documentation so i can learn the process.
If this is a WCF based service you can achieve the desired result by looking at the Instancing and Concurrency options available.
More info here
Related
I have a single API that sits behind an Azure API Management (APIM). Additionally, I have a few independent applications that need to consume this API via APIM (Lets say, application A, and application B - both of which are function apps). My question is, do I create two separate sets of APIs in APIM for each function app to consume the single API? Or should I send them through the same APIM API? What is best practice? I've searched Microsoft but haven't been able to definitively find anything yet.
Furthermore, would it make a difference if they were two SPAs consuming the API? (Let's say a consumer spa app, and an administration spa app)
The general approach is to structure you APIs in APIM around how they will be consumed. Splitting single API surface into separate products/APIs/operations in APIM allows you to specify different policies, access requirements, see those calls separately in logs and analytics e.t.c. So if in your scenario you do not have a need to distinguish between your two apps, there would be no need to split anything.
But say you want one app to use certificate authentication and another to rely on subscription keys - that would be a good case for having two products in APIm.
Similarly, say one app only needs one set of operations and another needs different one - this is a strong case for splitting into multiple APIs.
If all else fails, splitting APIs into logical blocks still makes sense. Depending on your subject area you may have:
Orders API
Users API
Products API
e.t.c
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 have an application for managing user data. All the business logic is encapsulated within a separate web api service, which the user management web application (among others) calls into. At the moment all web api calls are exposed (they are anonymous). However the web api sits on a separate domain and is only accessible to the applications that call into it.
Is there any benefit to adding bearer tokens and enforce authentication for each API call?
If the web api service is on a separate domain and adequately protected from the internet, then you dont need to authenticate at the service level for external security (over and above any application logins you have).
However, that is not to say that your application is not internally exposed and could be intentionally or accidentally called by malicious intent or an incorrectly configured application, for example, someone accidentally points a load test at production. For this reason I would secure it, at least with a HMAC if you dont want to implement full blown authentication.
EDITED: To add that with any public facing web real estate you should classify your data and decide the appropriate level of security to apply. In some circumstances you may not want to secure GETs of low sensitivity data. On the flip side, exposing GETs allows someone access to try denial of service attacks (by calling your API in a loop from multiple servers / a botnet). When it comes to POSTs, the risk is higher, since consumers will be inserting in to your datastore.
It's also always good to keep the OWASP Top 10 in mind when dealing with security.
We are developing an mvc web application and UI will be responsive, so don’t see any future requirement with web services required for native app that will consume services. However if we want to use Angular js in the future on the client side then yes it is required.
Now the questions is:
Will the performance better in case we use project libraries (Service library not web api) instead of using REST services created in Web api? Or there will not be much difference if we use rest services?
I believe including reference of service project libraries would be the best option if rest services are not required. As when request from client goes to server it don’t need another http request for calling rest services.
The best of both worlds would be including reference of service project libraries, but designing them in a way where you can have a very thin layer - an ApiController - to just handle the WebService security, if any, and call the logic.
If you do it right, the controller should have next to no code aside from calling your service classes.
Other advantage: you can implement a couple of those controllers exposing your services as REST services, just to prove that you got the gist of it and that your architecture works, and then, at a later date, expose all the other services as RESTful API as you need them, when you switch to AngularJS for instance.
Web services have an overhead proportional to the number of calls. Measure it by calling a no-op service 100000 times. You probably get 1000-5000 calls per second per CPU core.
This measure does not include network latency.
Depending on how chatty your app is the perf cost can be near zero or devastating.
When adding a web service layer the biggest concern usually is productivity cost. It is significant. You can no longer share objects between layers and rely on object identity. Everything is copied. No ORM use on the client for example.
Web services are not something you add lightly. Maybe you can architect your code as a library that is later amenable to be put into a web service as well. But that's hard thanks to the rather fundamental problem that state cannot be shared.
I would like to have a Traffic COP or Controller WCF Web Service that doesn't do anything with data but instead gives orders to another WCF Web Service to do so.
Could someone give me an example of how this might be able to be done. It would be preferable that I was not getting into any APM stuff. Instead just an observer who later gets to spin another one way contract to a WCF Web Service when it needs to after it sees that there are no more other WCF Web Services with the same meta data in memory or processing currently.
If this is impossible please say so. Unless you know a small example of how it is done. Maybe a pointer where somebody has already covered the topic?
Thanks apolfj
I don't really understand your question, but maybe this will help:
MSE is a "service virtualization" approach
Stocktrader has a WCF load balancer included in it.
Maybe one of them will fit your needs.
Having a 'traffic cop' service that all traffic goes through before it gets to the actual web service for processing will add extra overhead to your solution. Then you also have issues like once you've logged a call going to a particular web service, how do you find out if the response was successful? Then you hvae to do more logging of some sort and finally return the result to the client. If I understand what you were saying correctly (which I'm not entirely sure I do) you would be looking at something like;
Client -> TrafficCop -> Service1
Client -> TrafficCop -> Service2
OR
Client -> Service1 -> TrafficCop
...depending on where you want the entry point and what you need to do.
I would probably remove the traffic cop web service entirely and implement some API's for your service to implement and have each web service log some information before a service operation is called and after the operation has completed. I'd recommend you take a look at this link; http://msdn.microsoft.com/en-us/magazine/cc163302.aspx which covers behaviours, operation invokers and paramter inspectors.
This way each web service can log information, check access, rules, report errors before and after execution to a database or another TrafficCop web service if you really want. But I'd probably be inclined to just stick all that information in its own database. Thus each web service (depending on what you're doing) may have connections to two databases. One for the web service itself (if that's needed) and one to the TrafficCop / logging database.
At a later date you then may choose to add a website that pulls all the information out of the traffic cop database and allows you to easily browse / search it. It could highlight warnings or other issues your web services logged.
Summary
If all you need to do is logging and related functionality I would consider having each web service log and / or check rules and other things before and / or after a service operation is invoked. At a later date you could consider adding an admin site that surfaces all this information so you can easily keep an eye on how your web services are performing. You may even like to log information like how long it takes to respond to certain requests.
If this is not what you are after I would suggest you add more information and continue to keep your original question up to date.