User "get" api response formatting incorrect

[pb66]

When using the user/get.json api to retrieve user details eg

https://emoncms.org/user/get.json?apikey=abcd1234

We get a response like so

{"id":"1234","username":"JoeBloggs","email":"JoeBloggs@gmail.com","gravatar":"JoeBloggs@gmail.com","name":"Joe","location":"UK","timezone":"Europe\/London","language":"en_EN","bio":"","startingpage":"feed\/list","apikey_write":"abcd1234","apikey_read":"wxyz7890","tags":""}

notice that the timezone and the starting page path both have \/ as if the forward slashes are being escaped by the backslashes.

See closed issue #681 for a similar issue previously reported and fixed.

(tested on emoncms.org and older self-hosted emoncms, I do not have a fully updated emoncms in service at the moment)

[emrysr]

the response above is in JSON format. the slashes are required to escape the forward slashes.

I tested the above response on jsonlint.com and all was valid

[emrysr]

[pb66]

The response to the "pre-fixed" multigraph api in issue #681 also passes the jsonlint tests

as does the "post-fixed" response, the "fixed" version is however much neater, more (human) readable and easier to parse, simply put it's more "correct".

The "valid json" test is a bit of a low bar really, just because it's valid JSON format doesn't mean the content is correct. How many softwares will accept Europe\/London as a timezone?

Or even Europe\/-?-\/*#*\/<^>\/-London as that too is valid json

"the slashes are required to escape the forward slashes"

The slashes are no longer required to escape the double apostrophes in the multigraph api since being fixed, i suspected this to be of a similar nature.

[pb66]

Just for completeness, a non-escaped version of the reply would be valid JSON too.

See https://stackoverflow.com/questions/1580647/json-why-are-forward-slashes-escaped

It seems it is not required, it's just not prohibited.

Apparently it might be a quirk of PHP's JSON encoding to escaping slashes by default, there is a JSON_UNESCAPED_SLASHES option to the json.encode() function.

See http://php.net/manual/en/json.constants.php

Also of (unrelated) interest is the JSON_NUMERIC_CHECK as it has come up multiple times about numbers being formatted as strings in various feed api's and also possibly the JSON_PRETTY_PRINT as it would be so much easier on the eye to read

{
	"id": "1234",
	"username": "JoeBloggs",
	"email": "JoeBloggs@gmail.com",
	"gravatar": "JoeBloggs@gmail.com",
	"name": "Joe",
	"location": "UK",
	"timezone": "Europe/London",
	"language": "en_EN",
	"bio": "",
	"startingpage": "feed/list",
	"apikey_write": "abcd1234",
	"apikey_read": "wxyz7890",
	"tags": ""
}

rather than

{"id":"1234","username":"JoeBloggs","email":"JoeBloggs@gmail.com","gravatar":"JoeBloggs@gmail.com","name":"Joe","location":"UK","timezone":"Europe/London","language":"en_EN","bio":"","startingpage":"feed/list","apikey_write":"abcd1234","apikey_read":"wxyz7890","tags":""}

I assume here that the then decoded JSON would be the same data as the less-pretty formatted version, this would be of immense value to users reading through feed and input lists, I generally copy the replies over to an online json formater when I run api calls via the browser, using this option in emoncms by default could negate any need to do that.

Perhaps the solution for emoncms would be to create a global json.encode() wrapper function so that all JSON returned by emonCMS is consistent by just reusing the same function call throughout.