search

openBackhaul / ApplicationPattern

Pattern for REST servers
Apache License 2.0
6 stars 15 forks source link

To adjust the attributes of the PromptForRegisteringCausesRegistrationRequest2 callback as per the RegistryOffice specification #938

Closed PrathibaJee closed 9 months ago

PrathibaJee commented 10 months ago

The callback PromptForRegisteringCausesRegistrationRequest2 is specified to address the RegistryOffice://v2/register-application with the required request body. If this understanding is correct , kindly please clarify the following doubt ,

As per the specification of RegistryOffice://v2/register-application , the following attributes are mandatory 

- dispose-remainders-operation
- preceding-release-operation
- subsequent-release-operation

But in the request body of the callback PromptForRegisteringCausesRegistrationRequest2 , there is no required attributes described.

Proposal : The following required properties shall be included in the request body of the callback PromptForRegisteringCausesRegistrationRequest2,

- application-name
- release-number
- embedding-operation
- client-update-operation
- operation-client-update-operation
- dispose-remainders-operation
- preceding-release-operation
- subsequent-release-operation
- tcp-server
openBackhaul commented 9 months ago

The definition of the requestBody of the callback in the consuming application is basically redundant to the definition of the requestBody in the path definition of the serving application. Keeping both in sync is basically an effort, but also a potential cause of divergence. This is why I reduced the latest callback definitions to what I thought would be the "helpful minimum", which means the information about where the attributes' values shall be taken from. (No required, no min max of attributes, no templates, no examples, etc.)

Does this mean a disadvantage to the implementer? Which would be the information required by the implementer? What would be the ideal set of information for the implementer?

PrathibaJee commented 9 months ago

Thank you for explaning the reason behind. As you mentioned , we shall also look into the serving application to get the information. May be, we shall include which version of the serving application shall be refered for formulating the requestBody , so that the correct API shall be referred.

Also , please find the below details ,

Does this mean a disadvantage to the implementer? examples, templates are additional information, removing them will not be a problem. But , "required", "min", "max" statements will be useful for the implementer to correctly formulate the requestBody of a callback.

Which would be the information required by the implementer? As mentioned above , "required", "min", "max" statements will be useful.

What would be the ideal set of information for the implementer? Schema : "required" "properties"

Properties: "description" - about the value of the attribute "minProperties" "maxProperties"

What information will not be required for the implementer? The following are not required , Schema : "example"

Properties: The value for a requestBody property will be filled based on the details provided in the description. The consuming application will not do the validation of the data provided in the requestBody. And the serving application will do the data validation of the requestBody. So ,the following information will not be used by the implementer to formulate the callback, "pattern" "enum" "minimum" "maximum" "minLength"

openBackhaul commented 9 months ago

Changed as initially proposed.