You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@mikekucera suggested this for a command he's building.
As it stands now, the parser requires that every parameter be a string. This makes passing JSON messy, because it requires escape characters to process correctly in the CyREST command endpoint.
For example, if we want to pass this as the person parameter:
That makes the process more cumbersome than it needs to be.
A solution would be to treat every field the CyREST command endpoint sees as a String with the exception of any that appear as more JSON, in which case, the JSON itself would become the String passed to the command, simplifying the above to something like this:
The role field gets treated as a Java String.
The JSON in the person field gets 'flattened' into a Java String.
The downside to this is that we end up treating all JSON fields received by the CyREST command endpoint this way, removing the possibility of using JSON any other way within the CyREST command endpoint. An argument follows which says if we're really that invested in using JSON, maybe JAX-RS is the better option.
The text was updated successfully, but these errors were encountered:
@mikekucera suggested this for a command he's building.
As it stands now, the parser requires that every parameter be a string. This makes passing JSON messy, because it requires escape characters to process correctly in the CyREST command endpoint.
For example, if we want to pass this as the
person
parameter:we end up having to send this:
That makes the process more cumbersome than it needs to be.
A solution would be to treat every field the CyREST command endpoint sees as a String with the exception of any that appear as more JSON, in which case, the JSON itself would become the String passed to the command, simplifying the above to something like this:
The
role
field gets treated as a Java String.The JSON in the
person
field gets 'flattened' into a Java String.The downside to this is that we end up treating all JSON fields received by the CyREST command endpoint this way, removing the possibility of using JSON any other way within the CyREST command endpoint. An argument follows which says if we're really that invested in using JSON, maybe JAX-RS is the better option.
The text was updated successfully, but these errors were encountered: