To support apps which want to collect many changes and submit them together (to preserve bandwidth, or improve performance, or deal with being offline), reading lists should support batch operations (e.g. creating or deleting many list items at once).

To decide:

• which operations should this include? (list item creation/deletion? list creation/deletion/update?) *all of those*
• should there be a batch version of each endpoint (e.g. POST /lists/{id}/entries/ could take an array of list objects instead of a single one - a bunch of work but would make it possible to implment them efficiently with batched DB queries) or one single batch that takes a list of [operation_type, param1, param2...] items (easy to do, but we'll have to translate them to lots of single-row DB writes)? *extra parameter for each entry point*
• how do you pass an arbitrarily long list of paramters to the action API? *JSON in parameter*
  • use an x-www-form-urlencoded parameter such as project1|title1|project2|title2|... combined with unit separators (ugh)
  • use a JSON-encoded string as an x-www-form-urlencoded parameter (double ugh)
  • use JSON in the POST body (a departure from API conventions; we claim that the API supports XML etc. clients as well)

To support T184680: Update duplicate handling in reading lists API, batch responses (at least in the REST API) should be in the form of [{"id":1}, {"id":2}] not {"id":[1,2]}

Todo:

• add batch support to MW API
• add batch parameters to REST proxy
• make batch commands single queries in the DB - T187131: Support batching in ReadingLists database layer
• make sure character normalization still works with JSON input + apply size limits to JSON - T187103: Add size limits and character normalization for the ReadingLists batch APIs