[API][Request] Modification to payload structure for collected_items POST

Not sure how easy this would be to implement...

Looking at POST:/users/{user_id}/collected_items, the payload schema accepts a str(<JSON Dict Obj>). Ideally this would have the same JSON Dict nested as a list element. Example (using api example):

[
{
"type": 11331,
"issue": 63444,
"quantity": 1,
"grade": "vf",
"for_swap": false,
"private_comment": "Test with the API",
"price": {
"value": 76,
"currency": "EUR"
}
}
]

This way when uploading 100 coins (or over 1000 in my case), they can be sent as a batch and processed by the server, rather than needing to sending to send 100 (or over 1000 in my case) individual API calls. CPU IOPS are typically cheaper than Network IOPS.

I have zero idea how easy/hard this would be to implement knowing nearly nothing about the construction of your backend/code, so I wouldn't deign to suggest you could 'just do a thing'.

Normally I wouldn't worry about it, but with a 2k query per month limit, this would be very easy to hit. I can appreciate however, keeping this limit in place for abuse reasons.

Thoughts/Opinions? Thank you again to the Numista team for being so amazing!

I see the use case, but batched API calls present one issue: what to do if one of the operations should fail (missing required fields, etc.)? Should the whole batch fail (and rollback changes, if occurred), or should it return a list of successes and a list of errors?

Some complexity arises from the fact that POST methods on REST APIs (and INSERT operations in SQL) are not idempotent.

Agreed that there are certainly difficulties that are not apparent. Thats why I wanted to ensure I didn't commit the cardinal sin of: "Just add a loop easy" because that would be obtuse of me :D

I just wanted to call it out for consideration. It would be completely reasonable to just say "nah we will leave it alone and handle api quotas ad-hoc"