Mapping of production URLs to be routed to citoid:
Service location: citoid.discovery.wmnet
Service port: 4001
Use TLS: ?
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Stalled | None | T324931 Clean up open RESTBase related tickets | |||
| In Progress | None | T262315 <CORE TECHNOLOGY> API Migration & RESTBase Sunset | |||
| Open | None | T380348 [EPIC] Re-route services through RESTGateway and remove code from RESTBase codebase | |||
| Open | None | T361576 Switchover plan from restbase to api gateway for Citoid |
I think this is done here:
https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/973362
After spending some time on this, I think we might have some difficulty with supporting the third citoid pattern of rewriting $site/v1/data/citation/$format/$search to /api?format=$format&search=$search. Envoy's support for this kind of mangling isn't very complete as it's something it kinda expects services to do elsewhere.
I'll still keep looking at it but if there were a way we could just go on with the first two url patterns of $lang/v1/data/citation/api?format=$format&search=$search and $lang/v1/data/citation?format=$format&search=$search being rewritten as /api?format=$format&search=$search it'd be easier.
This seems easiest to me too.
We don't strictly need to support $lang/v1/data/citation?format=$format&search=$search or $lang/v1/data/citation/api?format=$format&search=$search. Incoming requests with get parameters were deprecated many years ago and everyone moved to the restbase pattern. This was more a nice to have.
I've restored my old patch which supports the native rest pattern which would not require any rerouting by envoy, and would just natively serve the restbase paths from the root, but it'll:
a) need some rebasing.
b) I've just realised the swagger docs served from ?doc are for the api/endpoint, and there aren't any for the restbase pattern, which I guess lives in the restbase repo. So basically if served as is would have the wrong docs, which I guess needs fixing before merged.
The api/ route is left in the service but we don't need to surface that to consumers because they're using the restbase patterns anyway, but it would also be okay if it was surfaced. (It was left into the service itself primarily for people who are hosting the service using the native api and not behind restbase.).
As a compromise would it be possible for us to have support in citoid for a pattern that natively supports some kind of data/citation/format/search query without using GET parameters?
@ppelberg I'm adding Editing-team, but please correct me if I'm wrong. We are ready to work on the REST Gateway routing for this service but it's currently blocked by the remaining work on this task.
Please let me know how I can support on the prioritisation of this task.
Citoid now natively supports the restbase-like pattern, so this should now be unblocked. (Deployed 20-11-2024)
Once we do the switchover,
Citoid endpoint:
/api?format=<format>&search=<query>
Becomes optional, as that's what restbase is calling. Once restbase is gone, in theory we don't need that endpoint. That pattern was removed from public access at 1 May 2017. I'm not sure we should expose that endpoint to the public now that we made the service compatible with the restbase pattern natively?
If we end up *not* doing so, we should remove the swagger documentation for it.