I'm trying a new #API design practice... dunno what it's officially called
So I am trying this new API design concept. I know it has been done before but I do not know if it has an official name.
I need your help!
When you read this and you recognize it and know the name, let me know because I want to learn what it is really called. For now, I am going to call it, Front-End First API Design Pattern, or FEFADP for short... yea, we need a better name.
What do I usually do when I am building an API?
Usually, when I design an API, I am inside the guts of the API, vetting out all the details of what the API parts will be. I define the data each endpoint receives and the data each endpoint returns. I work through a lot of the error handling scenarios, figuring out which HTTP response codes to be used and what type of error messages to return.
After I have all of that figured out, I usually build a part of the app around that endpoint. Sometimes, I leave out the error handling until later but regardless, it is similar to that flow.
What am I trying this time when building an API?
This time, I created a bunch of endpoints I know I will need. These endpoints don't do much, they only return mock data. They also do not do anything to the data passed to each endpoint.
var mock_section = {
content: '__Some content__',
markup: '<p><strong>Some content</strong></p>',
_id: 1
};
...
.get('^/sections$', function(handle) {
env.response.statusCode = 200;
env.response.body = [mock_section, mock_section];
next(env)
})
.get('^/sections/:id$', function(handle) {
env.response.statusCode = 200;
env.response.body = mock_section;
next(env)
})
...
The way I am designing the API is directly from the implementation of the application I am building. I am literally building the client experience where I am implementing services within my app to hit these endpoints and modifying the mock data returned to what I need in the application. I am also adding new endpoints as I hit certain places within the app... ex. After I create a new section, I will need to edit that section. So I create an edit endpoint for that user experience.
How is this helping me?
It is allowing me to rapidly change the API design without a ton of time invested in developing it at first.
It helps me figure out what I need and how I will use it because I do not have everything figured out from the beginning. This has allowed my app development to be more flexible instead of working inside a rigid API which already exists.
Doing it this way also helps me find ways to optimize accessing data within the API so that I do not create odd scenarios where I would need to jump through hoops before hitting a specific endpoint.
What is next?
My goal is to develop the entire app following this design pattern, helping me shape what my API should look and act like. Instead of me guessing which endpoints I will need before building an app, I will know exactly what I need in my API because the app literally defined what is needed. From this, I will build the actual API which receives and returns for-realz data.
Boomski!
I will give an update in a bit about how this is going and I am curious on your thoughts.
Have you tried this before? If so, how did it go?
That is all,
Cal - out