I connected my swagger PetStore api to Azure using swagger Azure API Management integration.
Now that it made it in azure; Where do I implement the actual logic of querying my azure database etc?
Using swagger if I generate a Node server stub I get the following generated. But these are not available if I use API management integration.
In the Backend section I only see Logic Apps and endpoint options. I tried the Logic App stuff but it seems I need 50 logic apps if I have api that large...Am I missing something?
Maybe you need to use SwaggerHub.
The Swagger UI you are currently using belongs to the community version and should not support direct integration. Assuming there are 100 api interfaces, you need to add 100 times in azure apim.
I'm building a Xamarin mobile app, which offline-syncs using Azure Mobile App service.
A. Xamarin (mobile client):
Xamarin's docs show how to build an app and a local database (using the sqlite-net ORM). Models are annotated with various attributes.
B. Azure Mobile App service (server):
Azure's docs show how to define models in the mobile app (without sqlite-net), and define similar models on the server app (using a customised Entity Framework). The client models use different attributes, and the server models don't use any attributes and derive from EntityData.
But then the client has two databases - the "real" one (A), and the one from the Azure APIs (B).
Am I supposed to only implement (B)?
Which means, (A) is only if I want a local database, and I don't need the sqlite-net ORM at all?
If you're using Offline Data Sync in Azure Mobile Apps, then you shouldn't do A, since the local database is already created for you as part of the offline sync feature. You do B as part of the C# ASP.NET server programming model, or you can use Easy Tables with a Node.js backend.
If you don't want a cloud connected app at all and the data to be stored only locally (i.e., no offline sync with a service), then do A only.
Alternatively, if you want the ORM provided by sqlite-net (rather than just basic querying and CRUD in the Azure Mobile client SDK), you can define a custom local store based on sqlite-net. To do this, create an implementation of IMobileServiceLocalStore. The Mobile Apps client SDK is open source, so you can use MobileServiceSQLiteStore as a starting point.
I have a requirement to deploy multiple version of the same API app where the client older application use the existing and the new clients use the new api app which is got more functionality.
Is there a way to achieve this with Azure API Apps?
I have an article that shows how to do Transparent Versioning using API Management in front of API Apps.
The basic idea is that you have a version parameter in a URL and then use the set-backend-service to change which version of the API to access.
is there any way to publish my API in azure mobile service API instead of using its own. I want just to know it, because assume I have a backup server in amazon and as you know I don't have access to azure sdk in there and it means technically I cant use the API anywhere outside the azure.
Azure mobile services is actually based on the .Net web api in their C# flavor and on node.js on the Javascript side. You could surely write an API using those technology and have the same behavior. You will gain the fact of being more portable, however you will lose some of the preconfigured stuff from Mobile services.
If you are using .NET, please check this to see how to build a Web api! http://www.asp.net/web-api.
If you are using Javascript, here is where you should start : https://nodejs.org/
Both tech are quite easy to learn and super powerfull, have fun! When your API is built, you could just publish them as an azure Web APP (http://azure.microsoft.com/en-us/services/app-service/web/) or an Azure API (https://azure.microsoft.com/en-us/services/app-service/api/) instead of the mobile App
Hope it helps, if you have more questions, please ask!
You can create and publish your own custom APIs in azure mobile service. You could even access in via azure mobile service sdk in client by using "InvokeApiAsync<>()" method.
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/dn614130.aspx
If you want to access the api via fidder/httpclient than AZM SDK, pass the mobile service key in HTTP header as Name:'x-zumo-application' value:'application key from portal'
I've been reading a few tutorials now on deploying Web Apps and API Apps to Azure. However, I am still a little unsure as to why you would use one over another.
I can create a new .NET solution with API controllers and deploy this as a Web App, so why would I specifically require an API App? Are these optimized specifically for ASP.NET Web API, where as Web Apps are for delivering HTML?
Updating the answer to current state of Azure,
App Services now replaces all Mobile, Api and Web Apps flavors as a single app framework with all the functionality rolled over to make things more accessible across application types. Currently all of Web, Mobile and Api Apps are collectively called App Services. We still offer customer to be able to create a Mobile App and a Web App in the gallery but that is basically resolve into an App Service App.
https://azure.microsoft.com/en-us/documentation/articles/app-service-api-apps-why-best-platform/
Features for Mobile work for Web App as well such as Easy Tables and Easy API. And features for API apps like API Cors and API definitions now work on web apps as well. A customer can host a single web app to act as any mobile service or an api with all the features offered through the app services.
We also have a new service in preview particularly targeting API Apps by offering a management experience for your APIs, Basically you can control the generate try API pages, gather execution analytics, throttle and much more. Check out the feature blog to learn more about the Azure API Management Features. And yes you can host the APIs as a App Service App and hook things up with API Management.
https://azure.microsoft.com/en-us/documentation/articles/api-management-get-started/
There was a point in time when there were differences between the different app service types, but that is no longer true. The documentation now states:
The only difference between the three app types (API, web, mobile) is the name and icon used for them in the Azure portal.
So it no longer matters which app service type you choose to deploy to (unless you care what the icon looks like).
UPDATE
Function apps are now the exception. Creating a function app changes the user interface in the portal. The underlying web app, however, is no different. Setting an app setting named FUNCTIONS_EXTENSION_VERSION = ~1 turns any web app into a function app (minus the user interface in the portal).
There are many minor difference between Web API and API Apps, but the very notable and key differences are
Native Swagger implementation - When you create API App in Visual studio, swagger reference comes by default. Swagger provide very developer friendly features for API consumers to Interact with your API thru Swagger UI. Also Swagger based API's provides client SDK generation (both .Net based client and Javascript based client) which makes easy to call API's just like regular method call.
Note: Swagger implementation on regular Web API is possible manually.
Ability to publish your API Apps into Azure Market Place. Azure Market Place is the public repository for all API Apps that can be consumed freely or by charge.
this 15 minute video from Channel 9 gives an excellent overview about Api Apps.
To supplement Greg's answer, Here's an even more recent article describing the differences.
To sum up:
"The key features of API Apps – authentication, CORS and API metadata – have moved directly into App Service. With this change, the features are available across Web, Mobile and API Apps. In fact, all three share the same Microsoft.Web/sites resource type in Resource Manager."
And here's another important note:
"If your API is already deployed as a Web App or Mobile App, you do not have to redeploy your app to take advantage of the new features."
This can depend on what you are trying to do, but you would use a Web API when you are creating a service. ASP.Net Web API is a framework for building HTTP services that can be consumed by a broad range of clients. This allows you to build it not only for a web app, but have it open to connect to Android apps, IOS apps, web apps, Windows 8 apps, WPF apps etc..
So if you need a Web Service but you don't need SOAP then you can use Web API.
Here my comments:
API app:
Used for specific functionallity. Triggering that functionality from an URL.
Can be used to use with GET, POST, PUT, DELETE.
Can receive parameters at BODY (Json).
Response with valid status code (fail, sucess.)
Web APP: An application deployed with multiple functionallity, for example
a catalog for create, update and delete customers or to create a complete ERP.
Function APP: Is very similar to API app,
Used for specific functionallity. Triggering that functionality from an URL.
Can be used to use with GET, POST, PUT, DELETE.
Can receive parameters at BODY (Json).
Response with valid status code (fail, sucess.)
Actually you can deploy your aspnet webapi on Azure WebApp and a self host on Worker Roles.
On WebApp (former Azure websites), it will be deployed on IIS, so you can take advantage of IIS features.