Close

Contract-First in API Management really

It’s tempting to import the Swagger file of a backend service into API Management and make it easy for yourself. It’s better to define the contract first and then ask the service providers to conform to this definition as much as possible. In REST it’s even easier because the standard contract is already defined for you with GET, PUT, POST and DELETE operations. The only thing
you will have to do is define the data contracts.

Now, what if the service provider can’t conform to the service contract? That’s where policies come in. Below are a few conformance issues and their solution. In the case at hand the backend service is a service around D365 Finance and Operations (f.k.a. Dynamics AX).

Issue:
Can’t implement URL for PUT /orders. Interface is generated and supports /SaveSalesOrderV2″.
Solution:
On the design tab of the PUT operation, define the URL path of the PUT method to be /orders.
Define inbound policy on the put operation:
<rewrite-uri template=”/SaveSalesOrderV2″ />

Issue:
Can’t implement PUT method, only POST.
Solution:
Define inbound policy on the put operation:
<set-method>POST</set-method>

Issue:
Return orderNumber on success. Return error message on failure.
Solution:
Define outbound policy on the put operation:

<outbound>
<base />
<choose>
<when condition=”@(context.Response.StatusCode == 200)”>
<set-body template=”liquid”>
{
“orderNumber”: “{{body.SalesId}}”
}
</set-body>
</when>
</choose>
</outbound>