For Finextra's free daily newsletter, breaking news and flashes and weekly job board.
The humble restaurant menu follows a common pattern where menu items are generally separated into a logical hierarchy. At the top level, we may have breakfast items, dinner items or drinks items. Each of these could be grouped further into categories like
meat dishes, fish dishes or pasta dishes (dinner items), and again into burgers and steaks (meat dishes). Each item is then described so that we (as humans) can make a choice on what to eat.
Now, consider making that same menu available as an API (for machine consumption). Think of the challenge that becomes immediately apparent; how do we describe objects that contain similar properties? How should we model burgers for example?
The natural human tendency might be to describe each burger as an object with defined properties. We may describe the “cheeseBurger”, the “baconBurger”, the “hawaiianBurger” – this follows the menu approach (the intended business purpose). Alternatively, we
could define the “burgers” as an array and identify each burger as an element with that array based on its property values.
There are a number of pros and cons to consider for each approach.
The “Named Object” approach
The “Array” approach
The choice of which approach to take depends on the domain you are modeling. However, as the domain expert, the decision is yours – just understand the consequences of your choice.
Chief Enterprise Architect API
06 Sep 2018
This post is from a series of posts in the group:
More generic posts and blogs relating with Application Programming Interfaces (APIs) including Open Banking and PSD2