Do you have an application landscape with different clients that have different responsibilities? For instance, you have a web page and an app with different users and different access rights to your API. If you happen to have very many different calls, it gets tricky for the developers to keep track of which call is meant for which application and users. In this article, I present my solution that helped the developers in my team a lot.
In case you are a bit lost and/or didn’t read my previous article about Generating Swagger Code for your flutter app, I described how to set up Swagger in your AspNet Core application to easily generate the client code for your flutter app. Of course, you can substitute the backend or the client technology with virtually anything you want.
Why exactly would I want to split my API?
Let’s say, we have a large backend application that offers a collection of services for several different client types (mobile apps, desktop apps, websites, …). It is most likely that not every offered call is meant for every client. Now, if you generate your Client API code using the swagger definition, it would make sense to only generate the client API code for the calls that are actually needed. Reducing the swagger definition to only the required calls has a lot of advantages:
- We get rid of unnecessary boilerplate in the client code.
- It reduces app size.
- It accelerates client app programming because developers do not have to crawl through unsupported APIs.
- By only providing allowed APIs, it actually improves data security because developers are less likely to use incorrect calls that transfer unnecessary data. Obviously, it does not replace a proper rights & roles or data security concept.
Is there a catch? Obviously, you have to make sure that the definitions are always up to date. Otherwise, the generated code does not contain the required APIs, some parameters might be outdated, and so on. Additionally, if you release new API versions frequently, my approach might not scale so well due to the generated overhead — depending on your project and API size.
#swagger #aspnetcore #software-architecture #api #flutter
