Here is the expected result on the API:

• /users/ID/ is unchanged
• /users/get is added, same as /users/ID/ but allows to specify multiple users IDs. The server returns an array of all of these users (still send the ID of each user in its data, this way the users do not have to be sent in the same order as they were requested. This might allow future threading optimization (because the order is pointless anyway and that the lib will check the correspondence of IDs anyway))
• /areas/ID/own/ only returns an array of the IDs of the posts (posts should not be nested)
• /areas/ID/ only returns an array of the IDs of the posts (posts should not be nested)
• /areas/ID/ID/ returns the data of the post with comments included, but neither the post's author or comments' authors are (users should not be nested)
• /areas/ID/get/ returns multiple posts, in the same way as /users/get (this is optional since posts don't need caching as badly as users do, since you don't often need to go back to old posts)

Until this is implemented, the Java lib will ignore everything that is not an ID in the above-mentioned requests. This way, the implementation of this task will be very fast.

Until then though, the lib will be getting a lot of unneeded data (I will not implement the reading of nested objects with cache verification since it's going to get deprecated in the near future anyway).

Currently there is no way to get a specific draft's data. Before this, the solution was to get the list of drafts with their data nested, but this is going to be removed.

An API endpoint at GET /areas/ID/drafts/ID/ would be necessary to update the local cache for a draft.

This could be replaced by T290, which gets the same results in a non-breaking way.

In T256#4663, @CLOVIS wrote:

This could be replaced by T290, which gets the same results in a non-breaking way.

So, do we replace it or not? @WyldBot @Info-Screen

I'd like to keep this one, because it removes unneeded nesting in serializers and therefore having data in multiple places

Okay. I thought about the other because it's not breaking (and more detailed)

This is why we need a versioned API