The simplest API we can use for this is wbsetclaimvalue: action=wbsetclaimvalue&claim=ID&value="VALUE"&snaktype=value&token=TOKEN. However, this won’t work when we want to edit qualifiers or references later, or want to support edit flows that edit one or more statements. For that, we’ll need to use wbeditentity. And I think we should consider using that module right away – we don’t need to send it the full entity data, this is a working example for the data parameter:

{"claims":{"P236":[{"type":"statement","id":"Q50$fc414696-44fa-0942-e531-95f315e7c0bb","mainsnak":{"snaktype":"value","property":"P236","datavalue":{"type":"string","value":"7722dd"}}}]}}

We only need the property ID, statement ID, and value (assuming that “main snak”, “custom value”, and “string” are hard-coded limitations for the time being) – barely more than for wbsetclaimvalue. Currently, wbeditentity results in less useful edit summaries, but that’s already being improved independent of this task (see T220696).

One drawback of wbeditentity is that it responds with the full new entity data, which is wasted bandwidth for us (we’re about to reload the page anyways). Perhaps we should add a parameter to control/reduce the response – I assume there are other users that don’t need the full response either.

During task break-down we decided to no implement the context-aware (disabled if nothing is changes yet) save button yet => T230342. /cc @Charlie_WMDE

note: we need an extra ticket for the close button and its behavior