[Mochi] - Declarative system description

[hhalex]

Here let’s talk about improving the YAML syntax to describe mocked systems

[hhalex]

Api proposal with folders:

config/

• system1/
  • api.yaml
  • v1/
    • api.yaml
  • v2/
    • api.yaml
    • api2.yaml
    • shape.yaml
• system2/
  • api-success.yaml
  • api-error.yaml
  • api-shape.yaml

Result:
mochi.com/system1/routes*
mochi.com/system1/v1/routes*
mochi.com/system1/v2/routes*

mochi.com/system2/routes*

[hhalex]

The root config folder consists of subfolders, representing systems to mock. The name of the subfolder is the name of the system and will create a prefix in the mocked routes.
Each subfolder representing a system will contain "apis". An Api is a set of routes meant to return responses. An api can be defined in a subfolder of a system, adding a prefix in exposed routes, or at the root of the system. If multiple apis are defined at the same level, a guard must be defined to select one or the other (a guard can be defined on a http header with a given value).

Example 1 - basic system with only one api at the root of the system
config/

• system/
  • api.yaml
    • POST /route1 -> 200 {content: "Hola"}
    • GET /route2 -> 302

curl --request POST mochi.com/system/route1
-> 200 {content: "Hola"}
curl --request GET mochi.com/system/route2
-> 302

Example 2 - basic system with versioned apis
config/

• system/
  • v1/
    • api.yaml
      • POST /route1 -> 200 {content: "Hola"}
      • GET /route2 -> 302
  • v2/
    • api.yaml
      • POST /route1 -> 200 {content: "Hola2"}
      • GET /new-route -> 203

curl --request POST mochi.com/system/v1/route1
-> 200 {content: "Hola"}
curl --request GET mochi.com/system/v1/route2
-> 302
curl --request POST mochi.com/system/v2/route1
-> 200 {content: "Hola2"}
curl --request GET mochi.com/system/v2/new-route
-> 203