How to interpret bodyRoot nested path/query/header/key properties?

[MaryGao]

This is a side issue when we ask the interpretion of Azure template and I found when handling the path and other parameters there exists in-consistancy for openapi emtters. I'd like to confirm if this is an issue or by design.

playground

op create(
  @bodyRoot
  body: Cluster,
): Cluster;

model Cluster {
  @path
  pathParam: string;

  @header
  headerParam: string;

  @query
  queryParam: string;

  @key
  idKey: string;

  prop: string;
}

The current interpretion are as followings:

	Request	Response
Path	request path	response body property
Query	request path	response body property
Header	request header	response header with same name
Key	request body property	response body property

Here are the questions:

• Both path and query property would be a normal response body property, is this expected?
• Can we differentiate request header and output header?
• Does @key property indicate read-only information and only for response body?

[timotheeguerin]

using @bodyRoot is the same as not using anything for the resolution of metadata properties. It just move the implicit body resolution to that property instead of the root of the parameters or response.

1. Both path and query property would be a normal response body property, is this expected?
   yes
2. Can we differentiate request header and output header?
   not sure what you mean, you have to check where its used
3. Does @key property indicate read-only information and only for response body?
   no, @key is a core concept that just mark something as a key, it has no effect on http library(rest does make use of it with resource but not http)

[MaryGao]

Thanks @timotheeguerin for sharing! Regarding the 2nd question, my point is both request and response has headers, if a model is shared by request/response, how do we differentiate that header is request header or output header?

[timotheeguerin]

They are both, you can use visibility to filter

[MaryGao]

With above interpretions could we document this done and let user know about this behavior?

It seems we leverage visibility to take the uage's role(input/output). What if we add read-only visibility to above path property, does that mean we still have that path paramter or not?

[timotheeguerin]

No path parmaeter is not there anymore playground

[MaryGao]

Got it and thanks!

[timotheeguerin]

can this be closed or there is more concern?

[MaryGao]

Closed as resolved.