Summary
Note: On June 1, 2020, this non-proctored certification exam was converted to a free quiz. Existing certifications remain valid for their full 2 year period.
A MuleSoft Certified Developer – API Design Associate should be able to create well-designed, modular API definitions using RAML 1.0 and Anypoint Platform. The MCD – API Design Associate (RAML 1.0) exam validates that an API designer has the required knowledge and skills to:
- Translate design requirements into API resources and methods.
- Use RAML to define API resources, methods, parameters, and responses.
- Model data in APIs using data types.
- Minimize repetition in API definitions using resource types and traits.
- Modularize APIs using libraries, overlays, and extensions.
- Specify API security schemes.
- Version, document, and test APIs and make them discoverable.
Get a datasheet for the exam here.
Format
- Format: Multiple-choice, open book, non-proctored
- Length: 47 questions
- Duration: 90 minutes
- Pass score: 75%
- Language: English
You can take the exam a maximum of 5 times, with a 24-hour wait between each attempt.
Cost
You can no longer purchase this exam.
Validity
The certification expires two years from the date you pass the exam.
Preparation
You can best prepare for the exam by taking the instructor-led Anypoint Platform: API Design course. Candidates should be familiar with all of the content in the course and be able to apply the concepts in actual projects.
Explaining RESTful API design |
- Describe the common web API formats including SOAP, RPC, and REST.
- Describe REST API architecture.
- List the rules for retaining REST principles in APIs.
- Describe design-first approach for REST APIs.
Resources
|
Translating functional requirements for APIs |
- Identify different categories and actions for a REST API.
- Convert categories to resources.
- Select HTTP methods to support the actions on the categories.
Resources
|
Describing API-led connectivity and the API lifecycle |
- Describe the API development lifecycle.
- Explain MuleSoft's API-led connectivity approach.
- Describe the API design lifecycle with Anypoint Platform.
Resources
|
Defining resources and methods |
- Use RAML 1.0 to create API definitions.
- Define resources and methods in RAML API definitions.
- Specify URI parameters for necessary resource methods.
Resources
|
Specifying responses |
- Describe response structure in HTTP methods.
- Use status codes in HTTP responses.
- Add error handling and caching information to HTTP responses.
- Select and specify the types of content returned in HTTP responses.
Resources
|
Documenting and testing APIs |
- Add documentation and description nodes to RAML definitions.
- Use the mocking service to create API endpoints.
- Use the API Console to test API endpoints.
Resources
|
Making APIs discoverable |
- Create API portals for learning about and testing APIs.
- Customize API portals with themes.
- Publish API definitions to the Anypoint Exchange for discovery.
- Gather feedback from API consumers.
Resources
|
Modeling data |
- Create datatypes and their properties for resources.
- Create examples for datatypes.
- Include datatypes and examples in resource methods.
- Create scenarios in API Notebook to manipulate data.
Resources
|
Reusing patterns |
- Create and reference resource types patterns for reusability.
- Use traits to modularize methods.
Resources
|
Modularizing APIs |
- Use libraries for greater API composability.
- Use overlays to internationalize resources.
- Use extensions to promote portability to test APIs in multiple environments.
Resources
|
Securing APIs |
- Define API security requirements.
- Use security schemes to apply resource and method level policies.
- Define custom security schemes for APIs.
- Apply an OAuth2.0 external provider policy to resource methods.
Resources
|
Enhancing API responses using hypermedia |
- Describe hypermedia.
- Simplify API discoverability using hypermedia.
- Use hypermedia to enhance API responses.
- Modify API definitions to generate state-specific client responses in resource methods.
Resources
|
Versioning APIs |
- Explain when and when not to version APIs.
- Describe the methods for versioning APIs.
- Document changes in new API versions using shared API portals.
- Deprecate older versions of APIs.
Resources
|