In order to unblock RESTbase derpecation, Citoid should expose an API compatible with the one that is currently exposed through RESTbase. This allows routing to Citoid to be taken over by the REST gateway.
Endpoint: /api/rest_v1/data/citation/{format}/{query}
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Add backwards compatibility shim for restbase | mediawiki/services/citoid | master | +154 -13 |
Change 907481 had a related patch set uploaded (by Daniel Kinzler; author: Mvolz):
[mediawiki/services/citoid@master] Add backwards compatibility shim for restbase
Change 907481 abandoned by Mvolz:
[mediawiki/services/citoid@master] Add backwards compatibility shim for restbase
Reason:
My understanding is this isn't needed and that the routing can be handled upstream.
Declining, because I was lead to believe this wasn't necessary after all (see abandoned change where I implemented it). Feel free to re-open if that is not longer the case as I can un-abandon it.
@Mvolz can you elaborate on the reasoning for not adding any compatibility changes? Looking at the resbase code I see that RESTBase does a sanitisation on the accept-language header.
Does that mean REST Gateway will cover that functionality or this is already covered by Citoid and RESTBase code is redundant?
This code either passes the accept-language header on directly, or passes the language the site is in. Rest Gateway would have to pass on incoming headers; I was lead to believe it would, that the accept-language headers come in and just go straight to citoid along with all other incoming headers.
But looking at it it looks like rest base also checked the incoming url for the site language and passed this along as the accept-language header. I assume this would be if someone was accessing the site /from/ the rest gateway, as requests from say, visual editor, already come with an accept-language header.
So yeah, this might be something we could add to Rest Gateway. Honestly it's more nice to have than anything... alternatively could have people put in their own accept-language header instead of passing on the one in the wiki automatically. Basically affects how people are using the gui api endpoint, not how the service functions inherently.
What sort of logic would this involve? REST Gateway will always pass on headers unless otherwise told to, but having service-specific logic in the gateway outside of generalisable features is something we'd like to avoid if possible.
I don't think it really needs to be done at all tbh. The old one just picked out the language from the site it was hosted from (i.e. if it was de, german) and passed it through as the accept-language header if none was included.
Change #907481 restored by Mvolz:
[mediawiki/services/citoid@master] Add backwards compatibility shim for restbase