Guidance on how to name hierarchical resources

[achew22]

I've read AIP-122 through several times and I am still uncertain about how to handle a situation where you are defining resources that exists inside of another resource. To concretize it, imagine that you were doing an AIP informed resource name for memberships in Google Groups.

1. When enumerating memberships it seems productive to name the relationship. That is to say, you might write the name for the membership as domains/example.com/groups/foo/memberships/[email protected]. This is preferable to domains/example.com/groups/foo/users/[email protected], where it is ambiguous if [email protected] is a membership, or possibly the owner of that group?

2. Assuming point 1 is reasonable, then the question comes of, what if there are different kinds of memberships that would be allowed. Google Groups can have memberships that are both users and groups themselves. That is to say I can take the [email protected] group and add it as a member of the [email protected] group and anyone who is inside of either group will receive mail directed at [email protected]. Also, for this example, please presume that it is possible to model membership information in a valid way for both groups and users (although if that is a thing that the AIP would recommend against, I would like to learn). Is the correct way to model this to treat names more as:

   1. domains/example.com/groups/foo/memberships/users/[email protected] and domains/example.com/groups/foo/memberships/domains/example.com/groups/baz?

      Is it weird to have two delimiters that are URL indicated in a row, memberships/users? There are no examples of this, so I'm reluctant to proceed without asking.

   2. domains/example.com/groups/foo/userMemberships/[email protected] and domains/example.com/groups/foo/groupMemberships/domains/example.com/groups/baz?

      This feels a bit odd, but may be correct due to:

      Field names may include a leading adjective if appropriate (such as string dusty_book).

      but that is for field names, not for collection names.

   3. domains/example.com/groups/foo/memberships/[email protected] and domains/example.com/groups/foo/memberships/[email protected]?

      Would it be better to not include the type information in the URL at all?
      In this situation how would you disambiguate between a group and a user of the same name having a memberships?

Sorry I couldn't find a better venue to ask than just in the GitHub issues for this.