Page MenuHomePhabricator

Batch requests
Open, Needs TriagePublic

Description

Currently, getting posts is done with:

GET /areas/AREA/
GET /areas/AREA/own/
GET /areas/AREA/ID

These are not modified, for backward compatibility. Instead, the following 3 endpoints are added:

POST /areas/AREA/batch/
GET /areas/AREA/list/own/
GET /areas/AREA/list/queue/

First, POST /areas/AREA/batch is used to get data about multiple posts at once.
It takes a JSON array of post IDs as parameters. The size of the array can be 1 or more.
It returns an array of the same size, which contains different objects like this:

If the requested post ID does not exist, or was deleted:

{
  "id": ID OF THE POST,
  "status": "deleted"
}

If the requested post does exist:

{
  "id": ID OF THE POST,
  "status": "success",
  "author": ID OF THE AUTHOR,
  "anonym": BOOLEAN,
  "subscribed": BOOLEAN,
  "created": DATE TIME,
  "active": BOOLEAN,
  "text": STRING,
  "image": STRING,
  "additionnal_images": STRING,
  "comments": [
    COMMENTS
  ]
}

These are the exact attributes currently given by GET /areas/AREA/POST_ID except that the status is added, and the author attribute refers to the ID of the author, and not of its nested data. Note that the comments' author field should also be the ID and not the nested author data (which gets very large because of the bio).

Next, GET /areas/AREA/list/own/ returns an array of the IDs of the user's posts (same data as GET /areas/AREA/own/ but without nesting). The array can be empty, but should always exist.

Finally, GET /areas/AREA/list/queue returns an array of the IDs of the posts in the user's queue in that area (same data as GET /areas/AREA/ but without nesting). The array can be empty, but should always exist.

Similarly, here are the ways we currently have to get users:

GET /users/ID

Because the ID is an integer, it is possible to add, without ambiguities:

POST /users/batch/

Which takes an array of user IDs and returns an array of the same size, which contains the data of the users as seen in GET /users/ID, with an additional status field (or only the status and user field when it doesn't exist).

Event Timeline

CLOVIS added a comment.Jan 4 2019, 4:07 PM

This task is an attempt to make T256 non-breaking, and cleaner by being more explicit.

WyldBot moved this task from Backlog to Implemented server side on the Web board.
WyldBot edited projects, added Client; removed Web.Mar 17 2019, 6:04 PM