One of our internal apis returns an array in which the first element is metadata about the request.

Why would anyone want to punish their users like that

If I'm doing multi threaded requests that need to be put back together in a single thread, then its a word of difference being able to match the response back to the request.

Otherwise, nope no idea why someone would do this.

But the response is usually something like
{
request{
Id: "some id I gave you"
},
response{
// the actual response in here
}
}

Is that bad? I had a project that interacts with google dialogflow and their API always returns the query I sent. Even the service account json I used, etc.

@fruitfcker @C0D4 I misspoke in the rant sorry, let me specify:

[
{ amount: 5 },
{ data },
{ data },
{ data },
{ data },
{ data },
]

@alexbrooklyn 🤨 nope, that's just asking for trouble if it's just another index in the array.

@alexbrooklyn could be one of those "comfortability features" no sane person would implement.

Eg. For paging

Or someone actually tried to implement a banana validation for empty response.

Banana validation as

amount: 0 is pretty much the same as len([]) - except for the case one has a bogus exception handling ala catch all and cannot distinguish between HTTP response error, JSON decode error and thus amount is the validation that the response was successful and is valid JSON.

Seen it. Gives migraine.

@alexbrooklyn that actually looks like textbook stuff when it comes to packets and such.
Like if you're sending a bytestream in some low level environment where len() isn't available maybe the response isn't even terminated - dunno the specifics but seen it a couple times (e.g. comunicating with a sensor from other hardware in some vendor specific scripting lang)

That being said it sounds like that's faaar from your application/stack and somebody just coulnd't shake old habits (or never bothered to think about the why)