"Attachments" are a generic way to ask for extra data when you issue a query.

For example, you can ask for the "projects" attachment to get information about project tags, or the "subscribers" attachment to get information about subscribers. These attachments are automatically provided and work on any object which can be tagged with projects or have subscribers.

Some applications provide additional attachments. For example, Paste provides a "paste content" attachment, which lets you fetch the content of the paste. By default, we don't return that, since it could be large and you don't need it for some use cases (like showing a list of pastes).

There are at least three ways badges could return awards:

Attachments: We could add an "awards" attachment. However, this runs into trouble because attachments don't have a standard mechanism for limits/pages, so we'd be forced to return a million rows if a badge had been awarded to a million users. This isn't great.

Separate Method: We could implement something like badges.awards.search to query for badge awards separately. This would work fine, but it's kind of clunky and awkward, and not clearly valuable on its own.

Separate Infrastructure: T5873 discusses possibly introducing new edge/relationship-oriented infrastructure for automatically constructing endpoints that query this type of data. This could potentially cover subscribers, awards, and other kinds of "potentially infinitely many" relationships.

None of these ways are clearly the right way, and we don't actually need this capability, so my recommendation for now is to simply not implement anything. We don't have enough information to choose the best approach and don't need to choose one, so we're best off just delaying the choice until later when we have more information.

(We don't really need these endpoints right now either, but the way forward for them is clear, and they're straightforward to implement, so they make sense to get through before unprototyping.)