I'm a bit confused about what you wish to convey through this article. Do you mean to say that we should try to define the scope of our application by defining each entity interacting with the app before writing APIs?
Thanks for the question :) What I'm trying to convey is that we should design APIs by exploring the application logic first. This exploration should happen apart from considerations about HTTP, database design, and system architecture.
Many experts suggest writing an OpenAPI document before writing any code. While this does push for a design-first approach, it forces designers to think in the context of HTTP and JSON. I believe this limits how designers can explore the application's domain.
In contrast to a design-first approach is a code-first approach. For this, people build the API first and then generate an OpenAPI document from it. The problem with this is that it can cause people to skip over the design step—you may get an API, but who knows if it's the right API.
These approaches have merit, but I feel they are lacking. I think it's best for people to find ways to explore the application logic and domain without thinking about external dependencies. An API is a delivery mechanism, and it shouldn't affect your application logic. Same goes for the database. I think the best way is to start by writing some code to test out the logic and then design an API around that.
This fits into a few architectural patterns that I've found very helpful.
I'm a bit confused about what you wish to convey through this article. Do you mean to say that we should try to define the scope of our application by defining each entity interacting with the app before writing APIs?
Thanks for the question :) What I'm trying to convey is that we should design APIs by exploring the application logic first. This exploration should happen apart from considerations about HTTP, database design, and system architecture.
Many experts suggest writing an OpenAPI document before writing any code. While this does push for a design-first approach, it forces designers to think in the context of HTTP and JSON. I believe this limits how designers can explore the application's domain.
In contrast to a design-first approach is a code-first approach. For this, people build the API first and then generate an OpenAPI document from it. The problem with this is that it can cause people to skip over the design step—you may get an API, but who knows if it's the right API.
These approaches have merit, but I feel they are lacking. I think it's best for people to find ways to explore the application logic and domain without thinking about external dependencies. An API is a delivery mechanism, and it shouldn't affect your application logic. Same goes for the database. I think the best way is to start by writing some code to test out the logic and then design an API around that.
This fits into a few architectural patterns that I've found very helpful.
I hope I didn't muddy the water :) I'm happy to answer any further questions you have if I didn't quite convey what I'm talking about.
Thanks for taking the time to give such a detailed reply!