Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T347303 Functionality REST API v2 | |||
Stalled | None | T307033 Filter elements of a statement structure to be returned by GET /entities/items/{item_id}/statements | |||
Open | None | T337374 Add a reference to a statement on an item or a property | |||
Open | None | T342994 Replace all data of an item/a property | |||
Open | None | T342996 Remove an item | |||
Open | None | T346645 Remove a property | |||
Open | None | T337823 Remove a reference from a statement on an item or a property | |||
Open | None | T337822 Remove a qualifer from a statement on an item | |||
Open | None | T337820 Add a qualifier to a statement on an item | |||
Open | None | T346647 All other API endpoints for qualifiers and references |
Event Timeline
Is there a rough timeline for when v2 is to launch? There's an open call for development against the REST API (at least, such projects seem to be favoured) and the Wikibase Community User Group (along with others) are considering applying for development grants, but we don't want to commit to implementing a tool before Christmas if the API won't even be available by then.
While most of these features are less relevant to Wikidata, they are more likely to be of interest to third-party Wikibase users, who might look to have (for example) a toolkit for a certain language exposing features of the Wikibase REST API and aiming for equivalence to the Action API. At the same time, v1 features may be sufficient for e.g. a revamped Cradle or its replacement.
Hiya, we don't have a timeline yet and I'm unsure if it'll be done by Christmas. v1 will definitely be ready before this summer and if an endpoint from the v2 functionality seems core for a tool that would be useful for the community, I can have that prioritized. In general though for the open call, the whole tool doesn't have to built on REST, using REST plus query service and/or Action API would be perfectly great.
Thanks for the clarification. We're still at the stage of figuring out exactly what to propose, though we have some ideas - it helps to have that guidance, so that if we find e.g. wbparsevalue is needed to validate data type values but has no REST equivalent yet, we can still use it