Wikidata talk:REST API feedback round

Feedback on the Wikibase REST API (July/August 2024)

The Wikibase REST API has been available on Wikidata since last year, but development has continued to produce v1, which will be a fully rounded product serving the foundational needs for accessing and curating data on Wikidata. It is slated to be available before the end of 2024.

Our goal with getting feedback is two-fold. Firstly, we’d like to understand from current and potential users what can be improved in the current API (i.e., the state it has been in so far) and to get an understanding of what to build next.

Questions

If you've used the REST API, what problems did you encounter?

Did you run into any bugs? Something you expected to work differently? Not a fan of the documentation?

If you have built a Wikidata tool in the past using the Action API, have you ever considered moving your tool to the REST API?

Yes/No?

What are potential blockers to making the switch?

For example, are crucial endpoints are missing for your use case or would the switch require too many resources?

Is there anything else you want to share with us related to the REST API?

Notes, questions or any other feedback

Lastly, if you’d prefer not answering these questions here, feel free to email me directly at ifrah.khanyaree@wikimedia.de

Feedback from BrokenSegue

How long have you been using or contributing to Wikidata? Please briefly describe what activities you usually do on Wikidata?

Wikidata Admin / Tool developer / WMF employee / maintainer of https://github.com/derenrich/wikibase-rest-api-client

If you've used the REST API, what problems did you encounter?

Documentation is good but I wish there were examples of how to use the PATCH endpoints. In particular I cannot figure out how to PATCH the sitelinks. See [1]

If you have built a Wikidata tool in the past using the Action API, have you ever considered moving your tool to the REST API?

I have considered it. I have built tools on the REST API. Porting is probably more effort than I'd want to spend. Also I still don't know what to do about the lack of a solution for [2].

While the REST API is nicer that the older API without good library support (python and js) there isn't a real incentive to use it especially since it has fewer capabilities.

What are potential blockers to making the switch?

Lack of batch requests is problematic for some use-cases. Lack of search.

Is there anything else you want to share with us related to the REST API?

I'm surprised there are no endpoints for references/qualifiers. A common thing I might want to do is to "add" a reference" to a statement. I know I can do this via PATCH to statement. Though I have no idea how to write the right PATCH statement to do that. Maybe I should write "nice" methods for doing those kinds of operations.

Why did you decide to replicate all the statement endpoints? I'm not sure why I'd ever use a request of the form /entities/items/{item_id}/statements/{statement_id}

I wish when requesting an "item" I had the option to get descriptions/labels for all the properties/entities used in the item. I end up having to manually making a whole bunch of recursive requests afterwards to be able to "understand" what the first request even means.

@Ifrahkhanyaree WMDE:

BrokenSegue (talk) 04:30, 8 August 2024 (UTC)!

Firstly, thank you for taking the time to write out feedback! This is all really helpful. I'll take the blockers into consideration for when we iterate on what to build next.

For your sitelink issue, from a quick look from my end - it seems like the endpoint for PATCH item might be missing "/sitelink/" in the path name? or perhaps using the PATCH sitelink endpoint might also be a solution

I've asked the engineers to take a proper look at the issue and I'll get back with an answer by next week

About the second point - so, you're correct, since the PATCH statement exists and allows for adding references, there was lower priority for building an endpoint for references and qualifiers though they are in the list. See here and here Happy to help with an example for doing this with PATCH statement if you'd like?

Why did you decide to replicate all the statement endpoints? By this did you mean replicate them because they're already in the Action API? or why we had "/statement/statement_id"?

For the latter, afaik, it was done to allow for the ease of dealing with specific statements. For the former, the goal was to have feature parity for the core endpoints that Action API provides.

For your last point, this was also requested already and we have it in the backlog but we're debating how we would implement this, since forcing it into the current REST API might not be the best option, But I'm happy to hear your thoughts if you'd like to share them

Cheers, Ifrahkhanyaree WMDE (talk) 13:12, 9 August 2024 (UTC)