Certified MuleSoft Platform Integration Architect

Question

Following MuleSoft-recommended best practices for API governance and API policies, a project team has used RAML specifications to document and publish the functional requirements and detailed design definitions for its APIs. Various stakeholders have used these API specifications to implement APIs.

Later, the project team requires every API specification to be augmented with an additional non-functional requirement (NFR) that protects backend services from a high rate of requests, in accordance with defined service-level agreements (SLAs). The NFR's SLAs are based on a new tiered subscription level—"Gold", "Silver", or "Platinum"—that must be linked to a new parameter being added to the Accounts object in its enterprise data model.

Following MuleSoft-recommended best practices, how should the project team now communicate the required non-functional requirement to stakeholders?

Explanation

SLA tiers limit the number of requests that a client application can make when enforced through an SLA-based rate-limiting or throttling policy. The API definition should document every element clients are expected to send, and MuleSoft supports placing reusable RAML content in API fragments published to Exchange and referencing those fragments from API specifications. Therefore, the shared fragment should define the common NFR, and every affected API specification should include that fragment and be republished so stakeholders receive the updated API contract. Traits & policies concepts of RAML/OAS based APIs, Reviewing SLA Tiers Concepts, Create and Publish an API Fragment in the Text Editor

Learn more

Certified MuleSoft Platform Integration Architect

AstroTutor

Notes

Readiness

QuestionQ15

Community Discussion