Closed bloomonkey closed 2 years ago
Yes, I think that makes perfect sense.
I'm going to look to implement wrapping both the request and response arrays in an object containing a field called data
. As @farwatch suggests, this has the advantage of allowing the addition of e.g. messages
, errors
etc.
Use of data
as a generic field name is consistent with recommendation here and somewhat with JSON:API
Posting on behalf of @farwatch...
It would be preferable if the api returned a response body which had an outer key to wrap the list of predictions e.g.
as when mapping the JSON to classes via jackson in springboot apps becomes a bit more intuitive.
The current format (with the array at the top level) requires the use of either type tokens, or some form of further wrapper class in the code (see https://www.baeldung.com/spring-rest-template-list#get-list for more info). Whilst not a huge problem, it would be nicer to not have to worry about this. It also makes the endpoint a little more futureproof as further keys could be added to the top level object if there was any information that makes sense at a batch level.