Address Issue #64

[RamTMO]

1. Address Issue qos-booking-and-assignment : Appropriate success codes should be returned #64
2. Clean-up description in for some end points.

What type of PR is this?

• correction

What this PR does / why we need it:

This PR fixes #64. It address the correct success return code (202 when needed) for all end points.

Which issue(s) this PR fixes:

Fixes #64

Special notes for reviewers:

Changelog input

- This PR returns the currect success code 202 when a async pending status is returned.  
- It also fixes some descriptions to reflect the correct behavior.

Additional documentation

This section can be blank.

docs

[RamTMO]

@hdamker and others: I have added 202 status code to handle async pending events. But I have noticed that I have one 'callbacks:' section in booking and one in assignement of devices. Do I have to have separate 'callbacks' for every operation that is async? I have reviewed commonalities but could not locate anything relevant. OpenAPI 3.0 spec seems to mandate this. Any input?

[hdamker]

But I have noticed that I have one 'callbacks:' section in booking and one in assignement of devices. Do I have to have separate 'callbacks' for every operation that is async?

@RamTMO I can remember that I had this question already before the 0.1.0 version and you had some argument(s) why it make sense for you to have two different callback targets. But I can't find it easily.

[RamTMO]

But I have noticed that I have one 'callbacks:' section in booking and one in assignement of devices. Do I have to have separate 'callbacks' for every operation that is async?

@RamTMO I can remember that I had this question already before the 0.1.0 version and you had some argument(s) why it make sense for you to have two different callback targets. But I can't find it easily.

@hdamker That is correct. It was considered to scale these APIs to support if booking is done by party-1 and assignements are done by party-2; so we addressed this with two different callbacks. But my question was different. More related to .yaml syntax and/or commonality requirements. I could not find one. In booking alone I have 'booking' as well as 'delete booking' as async end points. In 'booking' endpoint I have 'callbacks' section and but not in 'delete booking'. Is it okay? or do I have to duplicate the 'callbacks' code in 'delete booking' also. We can discuss this in our next meeing.

[RamTMO]

@Masa8106 Are you able to review this and other PRs? Appriciate it

[Masa8106]

@RamTMO , I have confirmed that all linting error was resolved.
I understand that your main proposal is to add 202 return code for async mode when needed.
Just for my clarification, in case of "creation" 202 return code means to pending for what? Is it for booking resource creation, or for booking completion including network provisioning?
So far I think it would be good to align this among related APIs. I would like to hear feedback from others before approval.

[RamTMO]

@Masa8106 Yes, that is correct. I just cleaned-up the success codes in this PR; especailly 202 will be returned when the status is PENDING for async operations. In addition, I have updated some comments.

Following is from the issue:

Asynchronous operations: Use 202 Accepted for requests that will be processed later. The response should provide a >>>mechanism for clients to check the status of the operation.

[Masa8106]

In my opinion, as the QoS B&A API is applicable for multi-device handling, I think there is need for async operation more.
As far as I reviewed the code, LGTM.