minor amendments to the parameters guide #182
Conversation
handrews
left a comment
handrews
left a comment
There was a problem hiding this comment.
@karenetheridge thank you so much for working on the Learn site!!!!!
I have one comment where I'm not sure what the right outcome is.
|
|
||
| > **NOTE**: | ||
| > `in: querystring` cannot be combined with `in:query`. | ||
| > `in: querystring` cannot be combined with `in:query` in the same endpoint. |
There was a problem hiding this comment.
@karenetheridge I had to think through it, but I think I get why you are saying "endpoint" rather than "operation" here. Clearly if there are Path Item Object parameter that use either of these locations, then all Operations Object parameters can't use the other one.
However, I think that if you do not have Path Item query parameters at all, then you would be able to define different Operations on the same Path Item, and each of those Operations could use either in: query or in: querystring without interfering with each other.
But I can see how "in the same operation" might cause people to not think about the Path Item Object level. Does this make sense? If so, any ideas on how to concisely explain it?
There was a problem hiding this comment.
I was going for the abstract operation described by the path-item and operation together. I think we've said "API endpoint" previously?
However, I think that if you do not have Path Item query parameters at all, then you would be able to define different Operations on the same Path Item
Yes, that's fine, as the two operations operate entirely independently.
There was a problem hiding this comment.
| > `in: querystring` cannot be combined with `in:query` in the same endpoint. | |
| > `in: querystring` cannot be combined with `in:query` in the same path item and operation combination. |
There was a problem hiding this comment.
@lornajane a little help on the wording here please :) (in all the free time you have)
There was a problem hiding this comment.
| > `in: querystring` cannot be combined with `in:query` in the same endpoint. | |
| > For each operation, if there are any parameters declared with `in: query`, then `in: querystring` cannot be used.``` | |
| I take the point about there could be some different ways to describe it but I think wherever they are declared, those are clearly parameters that apply to this operation and so it is clear enough |
| ### Parameter Location | ||
|
|
||
| Parameters can reside in different locations, indicated by the `in` field. The most common ones are: | ||
| Parameters can reside in different locations, indicated by the `in` field. The different locations are: |
There was a problem hiding this comment.
In the previous version, were we deliberately implying that there are other locations than these? Because that seems to be lost in this update. I can't think of another location...
|
|
||
| > **NOTE**: | ||
| > If any parameters are `in: query`, then `in: querystring` cannot be used. | ||
| > If any parameters are `in: query`, then `in: querystring` cannot be used in the same endpoint. |
There was a problem hiding this comment.
| > If any parameters are `in: query`, then `in: querystring` cannot be used in the same endpoint. | |
| > For each operation, if there are any parameters declared with `in: query`, then `in: querystring` cannot be used. |
Maybe this?
|
|
||
| > **NOTE**: | ||
| > `in: querystring` cannot be combined with `in:query`. | ||
| > `in: querystring` cannot be combined with `in:query` in the same endpoint. |
There was a problem hiding this comment.
| > `in: querystring` cannot be combined with `in:query` in the same endpoint. | |
| > For each operation, if there are any parameters declared with `in: query`, then `in: querystring` cannot be used.``` | |
| I take the point about there could be some different ways to describe it but I think wherever they are declared, those are clearly parameters that apply to this operation and so it is clear enough |
4 participants
No description provided.