[ 
https://issues.apache.org/jira/browse/GEODE-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Baynes updated GEODE-2794:
--------------------------------
    Description: 
Plain text is valid JSON, but is not supported by the REST API. Same issue for 
all primitive types: bool, number, arrays. Only objects are accepted.

Repro example below. Putting the same value from another client works, and we 
are able to get primitive values.
PUT /gemfire-api/v1/orders/234
Request body:
{code:javascript}
"hello"{code}
Response:
HTTP 400
Response body:
{code:javascript}
{
  "cause": "Json doc specified is either not supported or invalid!"
}
{code}
 

Wrapping the same request as:
{code:javascript}
 {"value":"hello"} {code}
succeeds (HTTP 200, and entry is saved).

Experienced on Geode 9.0.2.

Possible scenarios:
 # Session state info containing binary data could be managed manually by base 
64 encoding the entire session state object into a string (not boxed in another 
object).
 # Images are binary data which could also be base 64 encoded to strings.
 # If a user is already using Geode for write-through caching, some values may 
be primitive types and it is convenient and consistent to write them through 
Geode rather than stepping around the cache.

 

This problem also impacts the new client/server protocol, as it uses the same 
JSON processing. 

  was:
Plain text is valid JSON, but is not supported by the REST API. Same issue for 
all primitive types: bool, number, arrays. Only objects are accepted.

Repro example below. Putting the same value from another client works, and we 
are able to get primitive values.
PUT /gemfire-api/v1/orders/234
Request body:
{code:javascript}"hello"{code}

Response:
HTTP 400
Response body:
{color:red}
{code:javascript}
{
  "cause": "Json doc specified is either not supported or invalid!"
}
{code}
{color}

Wrapping the same request as:
{code:javascript} {"value":"hello"} {code}
succeeds (HTTP 200, and entry is saved).

Experienced on Geode 9.0.2.

Possible scenarios:
# Session state info containing binary data could be managed manually by base 
64 encoding the entire session state object into a string (not boxed in another 
object).
# Images are binary data which could also be base 64 encoded to strings.
# If a user is already using Geode for write-through caching, some values may 
be primitive types and it is convenient and consistent to write them through 
Geode rather than stepping around the cache.


> REST API Doesn't Accept Primitive Types as Values
> -------------------------------------------------
>
>                 Key: GEODE-2794
>                 URL: https://issues.apache.org/jira/browse/GEODE-2794
>             Project: Geode
>          Issue Type: Bug
>          Components: client/server, rest (dev)
>            Reporter: Michael Martell
>            Priority: Major
>
> Plain text is valid JSON, but is not supported by the REST API. Same issue 
> for all primitive types: bool, number, arrays. Only objects are accepted.
> Repro example below. Putting the same value from another client works, and we 
> are able to get primitive values.
> PUT /gemfire-api/v1/orders/234
> Request body:
> {code:javascript}
> "hello"{code}
> Response:
> HTTP 400
> Response body:
> {code:javascript}
> {
>   "cause": "Json doc specified is either not supported or invalid!"
> }
> {code}
>  
> Wrapping the same request as:
> {code:javascript}
>  {"value":"hello"} {code}
> succeeds (HTTP 200, and entry is saved).
> Experienced on Geode 9.0.2.
> Possible scenarios:
>  # Session state info containing binary data could be managed manually by 
> base 64 encoding the entire session state object into a string (not boxed in 
> another object).
>  # Images are binary data which could also be base 64 encoded to strings.
>  # If a user is already using Geode for write-through caching, some values 
> may be primitive types and it is convenient and consistent to write them 
> through Geode rather than stepping around the cache.
>  
> This problem also impacts the new client/server protocol, as it uses the same 
> JSON processing. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to