[QoS Booking And Assignment] `createBooking` returns HTTP 202 for asynchronous/pending bookings

[gmuratk]

Problem description

When the operator cannot confirm a booking synchronously (e.g. validation is deferred), the current API returns HTTP 202 Accepted with no bookingId. This is incorrect: the booking resource IS created immediately — a bookingId is assigned and the resource is accessible via GET /qos-bookings/{bookingId} and DELETE /qos-bookings/{bookingId} before the operator's confirmation arrives.

HTTP 202 semantically means "the request has been accepted but the processing has not been completed." For this case, the processing that is incomplete is the operator's confirmation decision — not the resource creation. Returning 202 without a bookingId misrepresents the API contract and forces consumers to treat an existing, addressable resource as if it does not exist.

Expected behavior

All createBooking outcomes — including the asynchronous/pending case — should return HTTP 201 Created with a bookingId in the response body. The bookingStatus field (REQUESTED) and an optional sink callback provide the async signalling; the HTTP status code should reflect the resource creation fact.

Alternative solution

Additional context

• Affected operation: createBooking (POST /qos-bookings)
• Affected response codes: 202 (to be removed), 201 (to cover all outcomes)
• Affected example: BOOKING_PENDING — previously omitted bookingId, description stated "No bookingId will be returned"
• CAMARA Design Guide reference: §5.7.6.1 Asynchronous Responses — mandates 202 when "an API request initiates an asynchronous process"; however, this section does not address the case where resource creation is synchronous but the business outcome is deferred. RFC 7231 §6.3.2 (201 Created) takes precedence when a resource is created.

[Masa8106]

This issue was addressed in merged PR (#139). So this issue should be closed.