I am looking for any option in Windows Azure API Management service, so that I may invoice/cost developers consuming my Web API, as per their number of calls to Web API. Everything I found under this service is quite easy to use and promising, including analytic which shows maximum details of how many times each endpoint is hit etc. The last thing I need is if there is a way I can attach some pricing model with Web API so that I can see total cost invoiced towards a particular developer/consumer for API calls he made.
Azure API Management doesn't have direct support for payments/invoicing. We are working on the management API (coming soon) that could be used for integration with 3rd party billing providers. Would love to hear more about you scenario - please email to apimgmt#microsoft.com
Related
My client wants to integrate with DocuSign but has a limited budget, enough to cover the DocuSign Basic API plan. This plan has limited functionality compared to the Intermediate and Advanced plans.
Meanwhile a Developer account has access to all features.
How do I know which endpoints I can use if I'm targeting a Basic API plan, such that when I go live, I know my integration will work on the Basic API plan?
The way we typically approach this problem is by ensuring that your client account can be used to perform the operations that your integration will be doing.
So, say client comes with requirement - I want your app to do X.
Ask them - can you do X manually from the web app?
If they can - your app will be able to do it.
It's not really "which API endpoints" but which features. The same endpoint can be used for multiple features and vice versa.
Explore with your client what they want to do, ensure they can do it from the web app - and then you can use the API to do it without any issues.
I have 7 APIs (API Apps) hosted in Azure App Service and I have a client app (SPA) which consumes all these APIs currently. For better maintainability at the client side, i would like to have a single entry point for all these APIs. Therefore, the APIs wouldn't be exposed to the client directly.
With the single entry point i can validate the authenticity (AD B2C token) of the client call and then route the request to respective API. In this case, the response from any API would return through the entry point to the client app.
I have couple of thoughts to implement this flow as below:
Azure API management would be a fit for my use case. However, the cost of the service looks little high for me.
Create one more API which would sit in-front of all the existing APIs, then it would act as an entry point of each request which comes from web app client. Here, for 'App Service Plan' a high end tier should be chosen to process thousands of request per second. I am expecting one thousand requests/second.
As i just started with Azure, i would like to take suggestions from you on achieving my use case. Please let me know your thoughts on suitable solution.
p.s, All the APIs are .net core web api (3.1)
Since you've already crossed out API Management, I would say creating a API "traffic router" is your best solution. You could use something like Application Gateway and use url routing to direct to a pool but you'll have to check the pricing to see if that works for you.
I would however, if it's not too difficult, place your 7 APIs into on one API project and just have the various controllers for your API endpoint. I certainly get if that's not possible. Should that be the case, I would place all API app services inside a VNet and restrict access so that only app services on that VNet could talk to it. That way, your "traffic router" API app can do the authorization and be able to talk to the other 7 API apps.
I see that I can either connect directly (through Rest HTTP requests) to Google Firebase API but I can also connect it to Azure Notification Hub. I also understand that Firebase is free while Azure isn't.
Can you kindly describe what is the benefit of connecting Firebase to Azure rather than directly connecting to Google's API (if any)?
I'm using ASP.Net Core MVC as my backend.
Thank you
If you are doing one push platform only (Firebase in your case) and only considering basic scenarios, then there's not much difference between using it directly or via Notification Hubs (NH).
However, NH provides you with a set of really powerful features:
Cross-platform SDKs to allow device registrations from all major OSes and a unified way of sending pushes no matter which platform they are on
A feature that is unique across similar services is tagging and routing
Templating
Basic or extended telemetry
And some other features.
So, in short, yes you can do everything that NH does by yourself. It's just you'll spend a lot of time (and money on resources required to run it) while doing it. And this is an out of the box solution that has been tested through years and is used by some of the largest products on the market.
Can anyone please point out any benefits of using Azure Mobile services vs using a plain Azure app service / clean web api? For a starter / project type for a backend mobile solution.
I have somewhat mixed feelings on why I would want to use Azure Mobile Services.
As far as I see on Azure Mobile services you have an easier way of authenticating, you can use the notifcations hub more easily
and you have the different "built-in" ways of handling data (table storage etc).
Usually you would want some custom logics, user registration and handling when users register to your backend and you would like a more solid way of handling
and storing the data not privided by the OOTB datastorage.
You might also have another preference than using the /Table/ odata-endpoint you get with it or end up doing lots of logics to make your DAO's return data in properly for the OData endpoints.
All these things; IMO makes it more difficult to make the API/backend clean when using Azure Mobile services rather than a simple Web API with OData endpoints and swagger documentet API that can be used in a mobile-app just as easy.
Implementing / handling authentication and notifications ++ in Web Api ain't that diffucult nor time consuming.
So my problem Azure Mobile services is that it tends to fine for dev / prototyping and testing, but it might get really messy really fast when developing a proper backend.
Any thoughts and reasons why one should choose one instead of the other?
Think of Azure Mobile Services as V1 and App Service/Mobile App as V2. While Microsoft hasn't announced that Mobile Services will be phased out in the near future, if you start a new project, you should definitively look at App Service.
due to the fact that many people are confused about wether to take Web API or Web App or something different. They are going to put it all under one name. The underlying technology will be the same "i think".
But now you'll have in your portal the opportunity to add mobile push notifications, or add your swagger api definitions.
So when you're goint to stick with App Services you're not going to limit yourself.
Even when you're going to take Web Api you'll get all the functions as if you would take an App Service (if i'm correct).
*Edit: I looked it up in the portal. As I said, my old Web App Projects have the same settings as Web Api projects. So you don't need to decide anymore which kind of project you're taking. You get all the benefits out of the App Service.
I have a WebAPI back-end for a mobile, and want to host it in Azure.
I am having a hard time figuring out the real differences between AMS and Websites.
All the articles I read about the subject talks about changes and benefits in general, and I want to understand specifically which new features AMS provides, and the benefits of hosting in AMS.
Authentication
In AMS I see the "IDENTITY" tab in azure portal. From what I understand, those 3rd party configs allow me to authenticate my users easily with google,FB etc. But this is just making the process more convenient and configurable via UI. In Websites, I can achieve the same functionality pretty easily using code from ASPNet.Identity and OWIN libraris.
Push Notifications
Again looking at AMS in the "PUSH" tab, I can see two mechanisms. The Notification Hub and 3rd party section.
The Notification Hub is nothing special to AMS, and I can get the exact same functionality when hosting in Websites.
The 3rd party section allows me to configure credentials to push services from Apple and Google (APNS,GCM...) and together with libraries in AMS namespace I can easily write code to communicate with those services.
But When hosting in Websites, in my back-end I can use open source libraries. For example, Moon-APNS to talk to APNS.
Scale
As far as I understand, both Websites and AMS allows the same scale functionality (One calls it Units and the other Instances).
Are there any big differences I missed?
Are any of the claims I made are incorrect?
It would be great if anyone could shed some light on the matter, specifically addressing all the 3 issues (Auth,Push,Scale).
That's a question I often get when I present Mobile Services at user group events.
For a .NET developer, there's nothing really special about Mobile Services since everything it offers, you can do it with a Website.
Mobile Services really shines for non .NET developers since you can have a complete mobile backend by writing scripts running on Node and Mobile Services abstract all the database and REST complexity.
I will likely get downvoted since I'll express a personal opinion but anyways: I see no obvious reasons for using Mobile Services if you're coding a .NET backend.
I think you are exactly the target customer for Azure Mobile Apps. You will get all of the power of having your own Azure Website (now rebranded as Azure Web App), with the additional convenience and client libraries of Mobile Services.
One feature of the client library that you may not have noticed is the cross-platform offline data sync capability. That's usually hard to build on your own, and we have an implementation that's conceptually consistent across all client platforms. (Plus, if you use Xamarin, you can share code between your client implementations.)
To be clear: Azure Mobile Services is NOT deprecated, and will not be until long after GA (general availability) of Azure Mobile Apps. Azure Mobile Apps is currently in preview.
The other big benefit of Mobile Services that you haven't mentioned is the client libraries for Android, iOS, Xamarin, and Cordova. If you already have a REST client library in your app and don't need to worry about multiple client platforms, then Azure Web Sites sound like a good way for you to go.
AMS by itself is built on top of Azure Websites. So you can actually implement everything in an Azure website that is available in AMS.
However, the good thing about AMS is that it allows you to quickly build the backend for a mobile app with CRUD operations, authentication/authorization and also provides client side libraries for different type of clients e.g., HTML, C#, etc. so we don't have to manually make the HTTP calls.
If you have need to implement the above functionality in Web API, it is quite an effort. Isn't it?