21
For previous third party projects that I worked on that required integration to NAV by consuming NAV SOAP services, I would usually create a codeunit to handle complex parameters and collections and publish that codeunit via page 810.
e.g.
COD50000.DoSomeStuffViaXML(xmlRequest: text; VAR xmlResponse: text);
COD50000.DoSomeStuffViaJSON(jsonRequest: text; VAR jsonResponse: text);
The benefit with this approach is I can send up very complex data to NAV and it will be transaction safe (very important since NAV web service integration is stateless). There is an obvious push everywhere for SOAP to die and instead leverage RESTful calls instead.
However, the BC Web API doesn't allow a mechanism to consume a codeunit function via HTTP POST. The BC Web API is only useful for pages and page extensions
Say I need to call a NAV via the Web API to first update a customer, then create a sales order immediately afterwards. This requires two Web API calls from my third party app (one for the customer endpoint, and another for the salesorder endpoint).
If an error occurs at the salesorder http endpoint, there is nothing I can do about the previous call to the customer endppoint call since the webapi call already completed and committed the transaction. It's dangerous.
I propose that the Web API allow NAV to expose codeunit web services as Web API endpoints somehow similar to SOAP. The rules would be very similar to SOAP restrictions (i.e. only allow certain parameter datatypes for public functions e.g. decimal, datetime, text, boolean, etc).
request parameters and values should be posted via the request body. VAR parameters should be returned in the http response body. Ideally both XML and JSON would be supported but I'd be happy if just JSON is doable.
Example:
COD50000.DoSomeStuff(intValue: integer, VAR strValue: text);
begin
strValue := strValue + ' world ' + FORMAT(intValue);
end
http request for JSON:
{
"intValue": 1,
"strValue": "hello"
}
http response in JSON
{
"strValue": "hello world 1"
}
What do you guys think?
e.g.
COD50000.DoSomeStuffViaXML(xmlRequest: text; VAR xmlResponse: text);
COD50000.DoSomeStuffViaJSON(jsonRequest: text; VAR jsonResponse: text);
The benefit with this approach is I can send up very complex data to NAV and it will be transaction safe (very important since NAV web service integration is stateless). There is an obvious push everywhere for SOAP to die and instead leverage RESTful calls instead.
However, the BC Web API doesn't allow a mechanism to consume a codeunit function via HTTP POST. The BC Web API is only useful for pages and page extensions
Say I need to call a NAV via the Web API to first update a customer, then create a sales order immediately afterwards. This requires two Web API calls from my third party app (one for the customer endpoint, and another for the salesorder endpoint).
If an error occurs at the salesorder http endpoint, there is nothing I can do about the previous call to the customer endppoint call since the webapi call already completed and committed the transaction. It's dangerous.
I propose that the Web API allow NAV to expose codeunit web services as Web API endpoints somehow similar to SOAP. The rules would be very similar to SOAP restrictions (i.e. only allow certain parameter datatypes for public functions e.g. decimal, datetime, text, boolean, etc).
request parameters and values should be posted via the request body. VAR parameters should be returned in the http response body. Ideally both XML and JSON would be supported but I'd be happy if just JSON is doable.
Example:
COD50000.DoSomeStuff(intValue: integer, VAR strValue: text);
begin
strValue := strValue + ' world ' + FORMAT(intValue);
end
http request for JSON:
{
"intValue": 1,
"strValue": "hello"
}
http response in JSON
{
"strValue": "hello world 1"
}
What do you guys think?
STATUS DETAILS
Needs Votes
Business Central Team (administrator)
Thank you for your feedback. Currently this is not in our roadmap; however, we are tracking it and if we get more feedback and votes, we may consider it in the future. Sincerely, Business Central Team