@GWicke @mobrovac @Pchelolo where would you prefer this to live? It would be a thin wrapper that makes one or two action API calls (and in one case some calls to the page summary service), reformats the results and returns them. (The draft routes are in T164990.) It would not cache data since all data involved is private. Would it makes sense to include into RESTBase itself, since there is very little processing involved? If so, could you maybe point me to a similar task from the past as a starting point?

In T168986#3543165, @Tgr wrote:

Would it makes sense to include into RESTBase itself, since there is very little processing involved?

Sounds simple enough, so +1 from me. Since these are user-related routes, I suggesting putting them under the global [wikimedia.org domain](https://wikimedia.org/api/rest_v1/), something like https://wikimedia.org/api/rest_v1/lists/{...}. Let the bike-shedding begin! :)

If so, could you maybe point me to a similar task from the past as a starting point?

Calling the MW API and manipulating the result ought to be similar to what is done in the summary end point, so you can take a look at its spec and the related JS module.

In T168986#3549110, @mobrovac wrote:

Since these are user-related routes, I suggesting putting them under the global [wikimedia.org domain](https://wikimedia.org/api/rest_v1/)...

Browsers have no way of sending authenticated requests to wikimedia.org, so it would have to be one or all of the wiki domains. (All of them is more comfortable for the clients in that they could reuse whichever domain they already have a login + edit token for, and spare a couple requests. Don't know if the app / Reading Web devs care about that.)

Oh right, good point. In that case, we can put the hierarchy under https://{domain}/api/rest_v1/data/lists/{...}.

@Tgr Just saw this and your question about domains… all works for me.

https://github.com/wikimedia/restbase/pull/887

The above PR has been merged into the reading_lists_beta branch. In order for you to be able to test it in beta, I have set up an extra RESTBase instance on deployment-cassandra3-01 in the deployment-prep project so that you can freely/easily test the Reading List service. The code is present in the /opt/restbase directory and is a direct checkout from GitHub so that we can easily update it if needed. This RB instance contains only the reading lists section of the API, defined in /opt/restbase/projects/reading_lists.yaml which is included in the config over at /opt/restbase/config.yaml (the config declares most BetaCluster domains + enwiki). The service is controlled by SystemD (known to it as restbase-reading) and its logs can be found in /opt/restbase/main.log. Feel free to poke around there and let us know if we can help with anything else here. Happy testing!

I have also set up a proxy so that this instance is accessible from the outside - https://restbase-reading.wmflabs.org/en.wikipedia.beta.wmflabs.org/v1/

Thanks @mobrovac & @Pchelolo!

There is now also a standalone labs test instance in case someone wants to try it out without manually copying cookies: http://readinglists.wmflabs.org/api/rest_v1/#/Reading_lists

In T168986#3703999, @Tgr wrote:

There is now also a standalone labs test instance in case someone wants to try it out without manually copying cookies: http://readinglists.wmflabs.org/api/rest_v1/#/Reading_lists

Neat! Does that mean you will be using this instance instead of restbase-reading? Can I retire that one?

In T168986#3705791, @mobrovac wrote:

Neat! Does that mean you will be using this instance instead of restbase-reading? Can I retire that one?

@Dbrant any thoughts? I don't need it myself; it was useful to verfiy that things will work with a somewhat production-like config, but I don't expect the RESTBase part to change in ways that require that to be verified again.

(The labs instance is a plain vagrant setup so it uses sqlite instead of Cassandra; I don't image that would make much difference.)

OK with me!

That swagger UI for reading lists is so colorful. ;)