|
|
Post by AMI_archerwen on Nov 24, 2023 4:26:43 GMT
According the SPEC, (1)If an action does not have any required parameters, the service should accept an empty JSON object in the HTTP body for the action request.As my understanding, In this situation (2)it also acceptable if we provide a real empty request (Don't provide an empty JSON object in the request).But I think it is not necessary to support the item(2), it is up to the vendor. Am I correct?  Thanks, Archer. |
|
|
|
Post by mraineri on Nov 25, 2023 17:05:08 GMT
Yes, it is acceptable to allow a client to provide an empty request body in this case. However, we find that clients tend to use empty JSON objects in these cases, and we'd prefer services support this approach.
You can always support both styles of request bodies and treat them equivalently to be as flexible as possible with different clients.
|
|
|
|
Post by jautor on Nov 27, 2023 19:16:23 GMT
I would absolutely recommend that you support both of these (when no parameters are required) without returning errors to the client. Allow either an empty JSON object or an empty request body. We have seen clients do both - and it has caused interoperability issues when the service rejects one method that another service allows (or requires!).
Jeff
|
|
|
|
Post by AMI_Mani on Apr 1, 2024 2:59:42 GMT
Hi,
Assume, Ejectmedia action doesn't support request data and empty request, empty object ({})would be enough for that action. If user passes some request data, do we need to return actionparameter unknown or ignore request data? I feel both are valid, throwing error as bad request with actionparameter unknown or ignore request body, can you confirm whether it can be implementation sprcific or needs to handle with any one option? If we have any details in specification, schema related to this, please point that
Thanks,
Mani
|
|
|
|
Post by mraineri on Apr 1, 2024 12:44:15 GMT
You're free to do either; we state this in the specification:
> If the action request contains unsupported parameters, the service shall ignore the unsupported parameters or return the HTTP 400 Bad Request status code.
If you do return a 400, then using the ActionParameterUnknown message from the Base Message Registry makes the most sense.
|
|
