Skip to content
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 Support for Commands #78

Open
dotasek opened this issue Mar 29, 2018 · 0 comments
Open

JSON Support for Commands #78

dotasek opened this issue Mar 29, 2018 · 0 comments
Assignees

Comments

@dotasek
Copy link
Contributor

dotasek commented Mar 29, 2018

@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:

{
   "name": "Hodor"
}

we end up having to send this:

{
   "role": "doorstop",
   "person": "{
      \"name\": \"Hodor\"
   }"
}

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:

{
   "role": "doorstop",
   "person": {
      "name":"Hodor"
   }
}

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.

@dotasek dotasek self-assigned this Mar 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant