When searching or looking for search suggestions (autocomplete), the server returns a lot of data, much of which is pointless and/or duplicated.
Both search and autocomplete responses returns the same JSON structure, but it's used in different ways. And in the case of autocomplete, it presents a huge data overhead.
Example autocomplete response:
{
d: [
{
"__type": "Nota.Lyt.Item",
"totalcount": null,
"index": null,
"author": null,
"title": "T",
"series": null,
"seqno": null,
"totalcnt": null,
"media": null,
"teaser": null,
"keywords": "Some book title",
"imageid": null,
"speaker": null,
"resultstatus": "OK"
},
... more results here
]
}
The only values that are useful are keywords
and resultstatus
. But resultstatus
is needlessly repeated for each result, although it pertains to the entire result set.
The response could be streamlined to simply:
{
results: [
"Some book title",
"Some other book title",
... more titles here
]
}
This would require much less processing on the client, and much less data transfer. Both of which are obviously very desirable on a mobile device.
The resultstatus
value can be left out entirely. Any special status values can be expressed in the response's HTTP status. I.e. if the server responds with 200 OK
the search can be assumed to have worked fine.
In the case of a search that returns no results, the resultstatus
value is set to "NORESULTS", although returning an empty results
array would communicate exactly the same. Alternatively, the server could in that particular case respond with 404 Not Found
.
All in all, the response data can be reduced by 80% with no loss of information.
When doing a "full" search, the server returns its results using the same structure, however it's more fleshed out.
Here's an example response:
{
d: [
{
"__type": "Nota.Lyt.Item",
"totalcount": "8",
"index": "7",
"author": "Some author",
"title": "Some book title",
"series": "SID0000000000",
"seqno": "1",
"totalcnt": "7",
"media": "XX,YY,ZZ",
"teaser": "This book is about etc etc...",
"keywords": "keyword1 ; keyword2 ; keyword3 ",
"imageid": "00000",
"speaker": null,
"resultstatus": "OK"
},
... more results here
]
}
Again, a lot of information is duplicated across each result, causing a lot of data overhead.
As before, the resultstatus
value can be left out entirely, since it can be expressed via the HTTP status, or is simply self-evident from the result set.
Also evident from the set, are the totalcount
and index
values. Since the results are returned as an array, those values are given anyway.
Oddly, the results do not actually (explicitly) return the ID of the book, which is by far the most important piece of information. Instead it returns imageid
which contains the book's ID, but isn't labelled as such. Why not call it id
? Even if it's the same value, I see no reason to label it as the image ID.
A lot of other values are not used by the client at present. But even leaving those values in place, the response can still be reduced to:
{
results: [
{
"id": "00000",
"author": "Some author",
"title": "Some book title",
"series": "SID0000000000",
"seqno": "1",
"totalcnt": "7",
"media": "XX,YY,ZZ",
"teaser": "This book is about etc etc...",
"keywords": "keyword1 ; keyword2 ; keyword3 ",
"speaker": null
},
... more results here
]
}
Here, the response is reduced by about 20% with no loss of information.