Open APIs

Hello all,

we are about to implement TMF645 v5 Service Qualification Management API, and I'm confused about the expected use of HTTP statuses 201 vs 202. (I'm aware that TMF645 v5 is currently a Preview version ...)

• TMF645 v5 defines a task lifecycle, which expects sync/async processing of Query/Check Service Qualification:

• The old v4 instantSyncQualification attribute is now deprecated, with a hint to use HTTP header Expect: 202-Accepted instead (but the attribute still remains in examples ...)

• TMF630 REST API Guidelines say about POST /resource:

  • "A successful creation MUST return a 201 Created HTTP code on success."

  • "A creation operation MUST return a 202 Accepted HTTP response code when the resource creation is asynchronous."

My interpretation is:

• for TMF645, the qualification resource itself is always created synchronously (at least copying the request data, assigning id/href, ...),

• only the business processing of the qualification result is sync/async, reflected by state (done vs acknowledged/inProgress),

• therefore, POST should always return 201 Created, even for "async" processing.

My questions:

1. Is TMF645 v5 intentionally not aligned with TMF630 here and does it require the use of 201 vs 202 based on sync/async processing of the qualification?

2. Is it practically feasible for implementations to decide before finishing the processing of a request, whether the response will be returned synchronously (and quickly) or asynchronously and thus choose between 201 and 202?

Thanks for any clarification and hints

------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------

Hi,

do you have a reference regarding this statement?

we use this API (V4) and we're migrating to V5. We intent to keep using instantSyncQualification

It is still defined in the OAS V5 and present in all JSON request examples.

Hello all,

we are about to implement TMF645 v5 Service Qualification Management API, and I'm confused about the expected use of HTTP statuses 201 vs 202. (I'm aware that TMF645 v5 is currently a Preview version ...)

• TMF645 v5 defines a task lifecycle, which expects sync/async processing of Query/Check Service Qualification:

• The old v4 instantSyncQualification attribute is now deprecated, with a hint to use HTTP header Expect: 202-Accepted instead (but the attribute still remains in examples ...)

• TMF630 REST API Guidelines say about POST /resource:

  • "A successful creation MUST return a 201 Created HTTP code on success."

  • "A creation operation MUST return a 202 Accepted HTTP response code when the resource creation is asynchronous."

My interpretation is:

• for TMF645, the qualification resource itself is always created synchronously (at least copying the request data, assigning id/href, ...),

• only the business processing of the qualification result is sync/async, reflected by state (done vs acknowledged/inProgress),

• therefore, POST should always return 201 Created, even for "async" processing.

My questions:

1. Is TMF645 v5 intentionally not aligned with TMF630 here and does it require the use of 201 vs 202 based on sync/async processing of the qualification?

2. Is it practically feasible for implementations to decide before finishing the processing of a request, whether the response will be returned synchronously (and quickly) or asynchronously and thus choose between 201 and 202?

Thanks for any clarification and hints

------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------

Hi Matthiu,
here it is,
TMF645_Service_Qualification_userguide.pdf, page 16 and 52 (numbers in PDF, not footer):

And OAS/swagger specification - TMF645-Service_Qualification_Management-v5.0.0.oas.yaml:
            instantSyncQualification:
              type: boolean
              description: >-
                A previous indicator which when the value is "true" means that requester expects to
                get qualifcation result immedi3ately in the response. If the indicator is true (or
                by default now without it) then the response code of 200 indicates the operation is
                successful otherwise a task is created with a response 201. For asynchronous, this
                attribute is now replaced by the header request "Expect: 202-Accepted"
              deprecated: true

Best regards

Jiri

Hi,

do you have a reference regarding this statement?

we use this API (V4) and we're migrating to V5. We intent to keep using instantSyncQualification

It is still defined in the OAS V5 and present in all JSON request examples.

Hello all,

we are about to implement TMF645 v5 Service Qualification Management API, and I'm confused about the expected use of HTTP statuses 201 vs 202. (I'm aware that TMF645 v5 is currently a Preview version ...)

• TMF645 v5 defines a task lifecycle, which expects sync/async processing of Query/Check Service Qualification:

• The old v4 instantSyncQualification attribute is now deprecated, with a hint to use HTTP header Expect: 202-Accepted instead (but the attribute still remains in examples ...)

• TMF630 REST API Guidelines say about POST /resource:

  • "A successful creation MUST return a 201 Created HTTP code on success."

  • "A creation operation MUST return a 202 Accepted HTTP response code when the resource creation is asynchronous."

My interpretation is:

• for TMF645, the qualification resource itself is always created synchronously (at least copying the request data, assigning id/href, ...),

• only the business processing of the qualification result is sync/async, reflected by state (done vs acknowledged/inProgress),

• therefore, POST should always return 201 Created, even for "async" processing.

My questions:

1. Is TMF645 v5 intentionally not aligned with TMF630 here and does it require the use of 201 vs 202 based on sync/async processing of the qualification?

2. Is it practically feasible for implementations to decide before finishing the processing of a request, whether the response will be returned synchronously (and quickly) or asynchronously and thus choose between 201 and 202?

Thanks for any clarification and hints

------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------