33
Issue
The current API suffers from two overall shortcomings as evident in multiple BC Ideas. These shortcomings are:
1. Missing entities in the API
2. Missing properties in existing entities in the API
Customers, ISVs and partners are forced to address these shortcomings on a customer-by-customer extension basis, which is a chore and a pain.
Pain
Currently, there are many ways to address this issue: Custom API pages, UI pages exposed as web services, transformation of aging SOAP-based C/AL codeunits, ODataV4 unbound actions. All of these share two characteristics: They are purposefully not using the standard API and they require AL developers. The use of UI pages exposed as web services is even an offical anti-pattern.
Idea (possible solutions)
a. Allow the API to be extended via a codeunit.
b. Allow the API to be extended by admin via a UI.
Benefits
Idea a. would allow partners and ISVs to use the API instead of "circumventing it".
Idea b. would allow admins to add entities and properties to the API through configuration, not code.
Why?
As mentioned, there are other BC ideas that address missing entities or properties, but in my humble opinion these are narrow in scope which hide a more general problem. I would like to illustrate why the problem is more general in nature with some examples.
Examples
- Say I wanted to use the API to get inventory per item variant per unit of measure per location. I cannot do this, because locations, itemUnitsofMeasure-relations and stockKeepingUnits are not entities in the API. If I could just add table 14, 5404 and 5700 as three new entities to the API, then I would be done.
- Say I wanted to GET item categories. If I use the API, then I do not get the parent-child relations, so I cannot recontruct the hierarchy externally. The parent-child relations are in page 5733 and table 5722, so it would "just" be a matter of adding a single new property to the existing entity 'itemCategories'.
- Say I wanted to add the LCY to the currencies entity, so consumers could infer which base currency to match all other currencies against.
- Say I wanted to use the API to get item attributes. I would probably want to add five new entities itemAttributes, itemAttributeValues, itemAttributeTranslations, itemAttributeValueTranslations and itemAttributeValueMappings based on tables 7500, 7501, 7502, 7503, 7505.
How cool would it be, if I could just add them to the API instead of creating individual custom API pages?
How would the Idea look when implemented
I am not a UXer. My best suggestion is an API Config Page similar to the way you define configurable packages in RapidStart. There you can define each table and field that are of interest to you. You could create similar API packages and apply/publish them to the API similar to how you publish web services.
I hope other partners and ISVs are with me. Your votes are highly appreciated.
Sincerely,
Dan
The current API suffers from two overall shortcomings as evident in multiple BC Ideas. These shortcomings are:
1. Missing entities in the API
2. Missing properties in existing entities in the API
Customers, ISVs and partners are forced to address these shortcomings on a customer-by-customer extension basis, which is a chore and a pain.
Pain
Currently, there are many ways to address this issue: Custom API pages, UI pages exposed as web services, transformation of aging SOAP-based C/AL codeunits, ODataV4 unbound actions. All of these share two characteristics: They are purposefully not using the standard API and they require AL developers. The use of UI pages exposed as web services is even an offical anti-pattern.
Idea (possible solutions)
a. Allow the API to be extended via a codeunit.
b. Allow the API to be extended by admin via a UI.
Benefits
Idea a. would allow partners and ISVs to use the API instead of "circumventing it".
Idea b. would allow admins to add entities and properties to the API through configuration, not code.
Why?
As mentioned, there are other BC ideas that address missing entities or properties, but in my humble opinion these are narrow in scope which hide a more general problem. I would like to illustrate why the problem is more general in nature with some examples.
Examples
- Say I wanted to use the API to get inventory per item variant per unit of measure per location. I cannot do this, because locations, itemUnitsofMeasure-relations and stockKeepingUnits are not entities in the API. If I could just add table 14, 5404 and 5700 as three new entities to the API, then I would be done.
- Say I wanted to GET item categories. If I use the API, then I do not get the parent-child relations, so I cannot recontruct the hierarchy externally. The parent-child relations are in page 5733 and table 5722, so it would "just" be a matter of adding a single new property to the existing entity 'itemCategories'.
- Say I wanted to add the LCY to the currencies entity, so consumers could infer which base currency to match all other currencies against.
- Say I wanted to use the API to get item attributes. I would probably want to add five new entities itemAttributes, itemAttributeValues, itemAttributeTranslations, itemAttributeValueTranslations and itemAttributeValueMappings based on tables 7500, 7501, 7502, 7503, 7505.
How cool would it be, if I could just add them to the API instead of creating individual custom API pages?
How would the Idea look when implemented
I am not a UXer. My best suggestion is an API Config Page similar to the way you define configurable packages in RapidStart. There you can define each table and field that are of interest to you. You could create similar API packages and apply/publish them to the API similar to how you publish web services.
I hope other partners and ISVs are with me. Your votes are highly appreciated.
Sincerely,
Dan
STATUS DETAILS
Needs Votes
Business Central Team (administrator)
Thank you for this suggestion! Currently this is not on our roadmap. We are tracking this idea and if it gathers more votes and comments we will consider it in the future. Best regards, Business Central Team