Intent 1: Service definition

[FabrizioMoggio]

Intent 1: #13 (comment)

[FabrizioMoggio]

Is creating a ServiceId a value?
Is this a proper Intent for an API Consumer?
Maybe it is easier to just go directly with Intent 2 and Intent 3 defining the Service as a input parameter that is an array of ApplicationIds rather than creating a specific endpoint to create a ServiceId

[FabrizioMoggio]

Option 1: Passing all Application Instance Identifiers
Pros:
Simplicity: No additional grouping logic or state needs to be managed by your API. The caller is responsible for maintaining the list of instance identifiers.
Flexibility: The caller can dynamically decide which instances to include for each API call, allowing more granular control.
Statelessness: Your API remains stateless since it doesn’t need to store or manage the concept of a "service group."
Cons:
Increased Payload: Every API call will need to include all instance identifiers, which could lead to larger payload sizes, especially if there are many instances.
Error-Prone: Callers need to ensure they always send the correct and complete list of identifiers, which increases the risk of errors or inconsistencies.
Performance: Parsing and validating a large list of identifiers with every API call could have a performance impact.

Option 2: Defining a Grouping Method
Pros:
Cleaner API Design: By introducing a service identifier, subsequent calls are simpler and more concise, as they refer to the service rather than a list of instances.
Reduced Payload: API calls require less data since only the service identifier is sent, which can improve performance.
Abstraction: Callers don’t need to worry about individual instances after the service is grouped, making the API easier to use.
Consistency: The grouping logic ensures the service definition is centralized and consistent across all calls.
Cons:
Stateful Management: Your API needs to manage the mapping between service identifiers and instance groups, adding complexity and requiring additional storage.
Overhead: Extra API calls are needed to create and manage groups, which might not be ideal for use cases requiring rapid or dynamic changes to the instance set.
Less Flexible: Callers may need to update groups frequently if the instance set changes dynamically.

Considering the Pros of Option 1, I suggest to adopt this approach.