Application Programming Interface (API) Solutions Architected

One of the most substantial challenges in system development is the application programming interface.  The result is (ideally) a stable and well-defined interface for your system.  That can be a struggle when your solution is not exactly stable nor well-defined.  Nevertheless, that does not excuse you from ignoring the API until implementation.  It needs to be addressed in the architecture from the start. A Basic Application Programming Interface When you know an API will be required, you can always take the simple route.  Review the core data items, and features then create a pass-through of sorts.  While this is not the most elegant solution (and not recommended), it is a start.  When you start with this approach, try to keep the endpoints minimal, and you can grow those properly as the system evolves and matures. Set The Stage The best map for your API is going to come from the user stories and requirements.  There are two primary reasons for an API.  You are either providing integration for external systems or an import/export feature.  That boils down to a modest API that has a few ways to extract or send in data in the latter case.  In the former case, you will be providing endpoints to match the user stories.  Therefore, your API will either be driven by your data structures or your feature set.  That is not to say you cannot do both.  An API is almost always some combination of those two areas of focus. Stay Ahead Of The Needs We started by mentioning that you can build a solution and then provide an API, or you can design the API before implementation.  You will find it far more challenging to "tack on" an API after implementation.  There are often assumptions made within an application that will not be valid once you open its doors via an API.

There are no comments yet.

Please log in to write the first comment.