“/participations/{ID}/participants” sometimes fails for valid participation IDs

[tripu]

eg, /participations/14935/participants?embed=true

Looking at some examples, I suspect that this query errors with a 404 when the participation is of type individual==true. It kind of makes sense, but this is the only case I've found until now in the API where I cannot fetch a (seemingly valid, logical) URL and be sure that it'll return something (a valid envelope containing an empty array, if nothing else).

Until I noticed this, a client like Unitas could reliably hard-code all the hierarchy of objects and that worked in all cases. This breaks that assumption, and makes it a bit more complicated on my side¹.

Can we have this method always return something valid (an empty list of participants, instead of 404)? Does it make sense?

---

¹ To discover related URLs dynamically à la HAL looks like the right thing to do, instead of hard-coding fields etc. But in practice, there would be several disadvantages to that:

• URIs could not be fetched in parallel if we had to wait for the result of each request to arrive, be interpreted, and extract all subsequent URLs from it.
• There are exceptions and special treatments anyway, so we can't avoid hard-coding names of properties and fields: we can't display user photos the same way we display textual fields; some values like dates, URLs or descriptions containing markup need manipulation/escaping; there are properties that need special treatment like self, _embedded, _links; IDs need to be translated into human-friendly labels (eg, “editor's draft” instead of editor-draft).
• Not all related URLs are sent inside _links (eg, info about a group does not include links to its services nor its users, even when it has some), so unless that relation is hard-coded, it won't be discovered by a client (am I right about this?).

Because of all those “irregularities” or special needs, I ended up hard-coding the hierarchy of objects in Unitas.

[tripu]

Ditto about the participations of the special group that is the Advisory Board: seems the only group for which retrieving participations errors: https://api.w3.org/groups/7756/participations?embed=true.

[tripu]

It's happening with other groups (not only with the AB); see participations of the Web Security IG: https://api.w3.org/groups/49310/participations?embed=true.

[jean-gui]

I think there's a misunderstanding about what /participations and /participations/xxx/participants are.
/participations lists all entities that signed the PP agreement and so only makes sense (and exists) for groups that are under the PP (which is why the AB and some IGs don't have that information).
A participation can either be an organization or a user. If it is an organization, then /participations/xxx means the (member) organization signed the agreement (through its AC Rep) and /participations/xxx/participants lists employees of this organization that are in the group (after being nominated by the AC Rep). If it is a user, then /participations/xxx means the user made an individual commitment and /participations/xxx/participants makes no sense, which is why it doesn't exist.

That being said, for all groups there is /groups/xxx/users listing all users of a group regardless of how they joined the group (nominated by their AC Rep, through an individual PP commitment, or directly for groups not in IPP). But I realize this URL is not linked from /groups/xxx, and that is a mistake. I'm going to open a new issue about that.

To summarize, /groups/xxx/participations should be used when you need to know who made PP commitments and /groups/xxx/users when you want to retrieve all users in a group.

Does that clear things up?