Mapping of production URLs to be routed to citoid:
Service location: citoid.discovery.wmnet
Service port: 4001
Use TLS: ?
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?