-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JSON responses are not always uniform when response contains an array #15
Comments
The REST Adapter Service has been implemented so that it does the message conversions between XML and JSON based on the messages that it receives. In other words, it does not read the schema of the message, but it tries to interpret the correct data type (string, object, array) of an element / property based on the data that's available in the message. Unfortunately, it sometimes produces the outcome that you described. For example, data about the available services is produced using the
Since the REST Adapter Service does not read the schema of the message, it does not know what kind of a data format it should expect - it only sees the data included in the message to be converted. Therefore, case 1 is interpreted as a string, case 2 is interpreted as an object and case 3 is interpreted as an array. Changing the current behavior so that the REST Adapter Service could reliably recognize the correct data type of an element would require processing the schema of the message to be converted too. Of course, it would require the schema to be available, up-to-date and accessible to the REST Adapter Service both on consumer and provider side. Since the conversion from XML to JSON takes place on the consumer side, the REST Adapter Service on the consumer side should have access to the provider side schema to be able to convert the message correctly. Therefore, implementing a generic support for this kind of conversions is very complicated and error prone. Another alternative would be to implement the support for predefined services, for example the metaservices provided by the Security Server. However, it does not remove the need to support all the options on the client side in all other cases. Regards, |
When calling some SOAP service which returns array of things, the response contains an array if there are more than one thing and object if there is only one thing.
For example calling ListMembers, the response might contain the following:
No services, services is an empty string:
Member has a single service, service is an object:
Member has multiple services, services is an array:
This gets cumbersome in more complex responses when parsing them and have to accommodate all three options every time.
The text was updated successfully, but these errors were encountered: