Repository navigation
The "members" attribute in the AWS service definition is literally a list of "member" objects #28
Description
In the AWS service definition you're using as a source for this, there's a "members" field:
"ListUsersResponse": {
"type": "structure",
"required": [
"Users"
],
"members": {
"Users": {
"shape": "userListType",
"documentation": "<p>A list of users.</p>"
},
...
}
You reasonably assumed that "members" is a structural thing to describe what members a "ListUsersResponse" has, and have changed it to "properties" in your generated OpenAPI spec:
ListUsersResponse:
type: object
required:
- Users
properties:
Users:
$ref: '#/components/schemas/userListType'
description: A list of users.
...
However, when hitting the API directly using https://github.com/okigan/awscurl and https://github.com/sverch/aws-signature-proxy, the response actually has "member" sub-objects in it:
$ https_proxy=localhost:8080 curl "https://iam.amazonaws.com/?Action=ListUsers&Version=2010-05-08"
<ListUsersResponse xmlns="https://iam.amazonaws.com/doc/2010-05-08/">
<ListUsersResult>
<IsTruncated>false</IsTruncated>
<Users>
<member>
...
<UserName>shaun.verch</UserName>
<Arn>arn:aws:iam::ID:user/shaun.verch</Arn>
...
</member>
</Users>
</ListUsersResult>
...
</ListUsersResponse>
When I hit an endpoint that returns multiple results (ListRoles), it actually returns multiple "member" objects rather than multiple "Roles".
Activity
MikeRalphson commentedon Mar 7, 2020
I think the renaming of
memberstopropertiesis correct here (to get a valid JSON Schema object from the aws-sdk "Shape") and the renaming ofmembertoitemsis also correct - even though we do it somewhat naively. What seems to be missing is anxmlObjectto tell OpenAPI tools that the individual array items should be wrapped in<member></member>tags.What I don't know is whether this is the case for all xml-based AWS APIs, so paging @pimterry in case we need to refine the logic further.
fix: add xml:{name:member} for lists, refs #28
MikeRalphson commentedon Mar 7, 2020
The AWS APIs on GitHub are updated now, it will take about 35 minutes for the CI job to finish to publish them to the APIs-Guru API.
sverch commentedon Mar 8, 2020
Based on these openapi docs, it looks like the
xml.namemember that you added in this commit actually changes the name rather than adding a new sub object when you have it on its own.Although looking further down that page, I think if you also add
wrapped : trueit will work.MikeRalphson commentedon Mar 8, 2020
The
xml.nameis set on the items of the array, not on the array itself, wherexml.wrappedwould be set.sverch commentedon Mar 9, 2020
Ah, so will setting
xml.nameon array items that are otherwise unnamed cause the items to be wrapped in another sub-object? I don't see anything here about it (this was just a quick search, and I don't know all the options for sure). Thexml.wrappedoption looks like it was for this case on the array itself, but if naming the sub objects does it too then that's perfect.pimterry commentedon Mar 10, 2020
In short: I have no idea 😃. I've done some digging though.
Your fix here is above for both
queryandrest-xmlprotocols. There are a few other interesting examples of each, so picking through a few of themrest-xmlprotocol AWS docs:Route53 (
rest-xml):The AWS response example includes:
I.e. with no
<member>tag. That doesn't match our latest OpenAPI spec, which now setsname: 'member'. The AWS spec for this looks like:Cloudfront (
rest-xml):Similarly the AWS docs for ListTagsForResource shows a response like:
Again no
<member>, and again our OpenAPI spec now includes setsname: member. The AWS spec for this case looks like:ELB (
querywith an XML namespace):Looking at the response from DescribeLoadBalancers for example, it seems like every ELB list uses
<member>wrappers. Notably the AWS spec doesn't uselocationNameanywhere. I think the spec that comes out here is correct.IAM (the original issue) is also using the
queryprotocol.So, maybe we should actually only do this for the XML
queryprotocol? It's possible that it's relevant torest-xmlbut only when an explicitlocationNameisn't provided, but I can't see any cases where that happens, so maybe not. Any other counter/supporting examples would be very interesting.sverch commentedon Mar 11, 2020
Well I can at least confirm with awscurl that this is what actually gets returned for that cloudfront request (and it has no "members", as described):
Partially revert 763ccf8, now only for xml query APIs, refs #28