Closed BenjaminPelletier closed 4 years ago
Group: no objections
Just thinking on this a bit more. One alternate approach is to change to a single field that is an enum. This may be better long term as you can add enum values if there are more subscription options, which is probably easier to do than adding new boolean fields.
The intent here is to allow the subscriber to indicate which data streams they want to receive. While it's not valid for a subscriber to have a Subscription with no data streams, any other combination should probably be ok. If we used an enum, the number of enum members would potentially grow as 2^streams as number of streams increased, so it seems more scalable to have separate fields. And adding fields should actually be easier than adjusting enums because an unknown enum field value would be rejected by a naive client (one implemented to just the standard without augmentation) but we specifically allow the addition of fields not defined in the standard, so a naive client would not reject, e.g., an extra "notify_for_foobar" field.
Currently,
notify_for_operations
andnotify_for_constraints
are both optional when PUTting a Subscription and the API does not explicitly specify that at least one of them is required to be true. This clarification should be added to the API.