- investigate current status of JSON-PATCH (is it still state-of-the-art?)
- investigate PHP tooling support for JSON-PATCH (compared to MERGE-PATCH)
- investigate solution approaches
- Three possible solutions:
- 1. Load item -> serialize -> patch -> deserialize -> save;
- 2. Translate patch request into something format agnostic (= events?) -> apply -> save
- 3. Load item -> serialize -> patch -> ReplaceItemStatement use case
- Thoughts on approach 1
- Way less effort, opportunity to use 3rd party tooling
- Implies the existence of some canonical json representation
- Tricky to fit into the architecture, mixing JSON formatting and modification
- Thoughts on approach 2
- More effort
- More control on changes as they happen, since we can validate each operation individually using domain objects instead comparing the original Item to the (deserialized) Item after the PATCH
- single operations may result in inconsistent statement state, e.g. change snaktype from novalue to value and only adding the datavalue in a different operation
- can be mitigated by using a builder object
- requires each value type to have 1. a class that creates events from patch operations, 2. an event handler for each event type, 3. a builder for the value
- need to figure out where to translate from JSON PATCH to events: should the use case request contain events or the raw JSON PATCH operations?
- Thoughts on approach 3
- can reuse validation of the PUT use case
- gets tricky if PATCH and PUT are supposed to have different behaviors wrt edit metadata (PATCH information is lost when we get to the use case)
- awkward, because the item gets loaded twice
- Three possible solutions:
Solution prototype with approach 2, and either 1 or 3:
- replace main snak value
- add qualifier