feat(AIP-121): Disallow recursive hierarchies

[noahdietz]

Simply disallow recursive resource hierarchies.

[jskeet]

Should we be a little more descriptive about what we're prohibiting here?

It's worth considering the Firestore API, where there are alternating document/collection elements, e.g. projects/x/databases/y/documents/people/jon/computers/panther... the resource isn't annotated, but has a comment explaining that the pattern is projects/{project_id}/databases/{database_id}/documents/{document_path}. Is that okay because it's effectively internal, rather than expressed in the proto itself? Would we want to prohibit it if we could go back in time?

[noahdietz]

Should we be a little more descriptive about what we're prohibiting here?

@jskeet yeah I was struggling to find a balance in using concrete examples while also avoiding repeating the AIP-122/AIP-123 guidance. This AIP being more conceptual makes me want to avoid getting into the implementation, but some more detail is warranted...I'll fiddle with it.

where there are alternating document/collection elements...projects/{project_id}/databases/{database_id}/documents/{document_path}. Is that okay because it's effectively internal, rather than expressed in the proto itself?

This is a tricky one. So if the document_path section is defined basically as ** i.e. "any amount of slash-separated segments", and if those segments alternate as "collection" "resource" as you mention, then one could say that firestore has a recursive resource hierarchy, even though it isn't formalized.

Would we want to prohibit it if we could go back in time?

Yes I think so. This might come out weird, but I always saw firestore's "document path" as basically dot-notation for navigating the blob, where the top-level of the blob i.e. .../databases/{database}/documents/{document} (but without the following /**) represented the actual resource. I don't think this is how resource name hierarchies are meant to be used though?