RESTful API Modeling Language (RAML) is a YAML-based language for describing RESTful APIs. It provides all the information necessary to describe RESTful APIs.

In RAML, we define API specifications like Resource, HTTP Methods, Traits, Query Parameters, URI Parameters, and JSON request and response schemas. For all the Headers, Queries, and URI parameters which we define in RAML, we mention the data type of the parameters (ex type: string) and specify whether parameters are mandatory or optional (ex required: true). 

Defining required attributes (ex required: true) for RAML parameters are optional; RAML applies the default setting if required attribute has not been mentioned specifcally for any parameters. However there has been a different default behaviors which can be seen using RAML in mulesoft anypoint platform and studio.

RAML 0.8 Specification

In RAML 0.8, the default value for a required attribute is false. So, if the required attribute is not defined specifically for any of the header, query, and URI parameters, the MuleSoft platform mock service treats it as an optional parameter.

Example:

queryParameters:
operation:
type: string
enum: [searchByCriteria]

In the above example, the query parameter will be treated as an optional parameter by the MuleSoft platform mock service.

Mule Studio also uses the RAML file inside project folder src/main/resources. On validating the incoming request against this RAML, the Studio also treats these parameters as optional. 

So, in RAML 0.8, Mule Anypoint Platform and Mule Studio behaviors are same and seem correct.

RAML 1.0 Specification

In RAML 1.0, the default value for a required attribute is true. So, if the required attribute is not defined specifically for any of the header, query and URI parameters, the MuleSoft platform mock service treats it as a required parameter.

Example:

queryParameters:
operation:
type: string
enum: [searchByCriteria]

In the above example, the query parameter will be treated as a required parameter by the MuleSoft platform mock service.

On validating the incoming request against this RAML file in Mule studio, it treats these parameters as optional.

So, in RAML 1.0, Mule Anypoint Platform and Mule Studio behaviors are different.

MuleSoft is working on this defect and hopefully will implement a solution in a future release.