To ensure that non-functional requirements, such as rate limiting, are clearly communicated and enforced in the designed API definitions, the project team should use API fragments for the appropriate policy. Here's why option D is correct:
* API Governance and Policies: Mulesoft's API governance framework allows the definition and enforcement of policies across APIs to ensure consistency and compliance with organizational standards. These policies can include security, rate limiting, logging, and more.
* Policy Fragments: By updating API definitions with policy fragments, the team can encapsulate the non-functional requirements within the API specification itself. This approach ensures that these requirements are an integral part of the API design and are automatically applied whenever the API is deployed.
* Publishing to Exchange: Publishing the updated API definitions with the policy fragments to Anypoint Exchange makes them available for reuse and ensures that all stakeholders have access to the latest, compliant API specifications.
Example of adding a rate limiting policy fragment to a RAML file:
#%RAML 1.0 title: Example API version: v1 baseUri: https://api.example.com/v1 ... /* Include the rate limiting policy fragment */ uses: rateLimitPolicy: !include rate-limit-policy.raml The rate-limit-policy.raml fragment might define the specific rate limiting rules as per the service level agreements.
References
* MuleSoft API Manager
* Defining and Using API Fragments