In the .Net world, your application will usually be an ASP.NET MVC application hosted in the internet, perhaps in SQL Server database to hosted data. In the ASP.NET application you will have all the usually suspect like business logic class, services, data access layer and etc.
But you will also have ASP.NET Web API controllers to enable the App to connect to server to send and receive data.
In addition to that, many applications will also have a UI as part of the same application to provide Admin and content editing features for the client App owner.
The UI components can simply be MVC Controllers and be used utilize in the same database business logic and service classes that they are used by API controllers.
Of course in the same MVC application, they can be web pages for the end users interact with the platform through the browser too.
Obviously many serious digital businesses come with a web base version and in addition to the native app. So that are more accessible and usable by their market.
This is how you can use the WEB API from Zebble applications.
Here we have a web api with the URL: https://My-domain.com/api/products which will return a JOSON of array of products.
Look at the server side api documentation later.
For now, we want to focus in the client-side coding in the mobile app.
In the UI layer app, we have a page that show the list of products. Data source of that list module on that page will be called Domain name class product which has a static method name getList().
To implement the GetList() method, we will use the class in our project named Api: BaseApi which inherits from the base class in Zebble. The base Api class is effectively like simple an agent to send http request to the server with some useful features such as exception handeling, cashing, offline supporting and etc.
Here is the implemention of GetList() method:
{
return Api.Get<Product[]>("api/products");
}
Caching the result
Get-based Web Apis are used to read data. When you invoke them for the first time, the situation is obvious in terms of error handling. But after a first successful call, if later on your app is calling the same URL again, the situation is different. In this example, they say that you have received a product's data from the Api once. If a few minutes later, the user goes back to product page, but this time there is no internet connection and so you can not get a fresh the list of products from the Api.
Instead of showing nothing or an error message perhaps, surely would be nicer to use the data that you previously received to give that functioning. So Cashing in this case would be great. Of course, in some other cases, this could call serious problems if the data you showing the user is not fresh. For example, it can confused the user or even call security or legally issues.