Amgine0
commented
6 years ago Use cases:
- Using Webtrees for collaboration (wiki-ish)
- External record editing (e.g. desktop editor)
- Bulk individual record imports via script
- Individual linking
- Addition management (UI js to bulk approve/discard contributions requiring approval, etc.)
- Communications
- User-to-user messaging
- Research tasks
- News block
- Using Webtrees as a repository
- External record consumption
- e.g. to embed a record in a third-party website, display in an app, federated search
- External resource consumption
- e.g. request media related to specific record, source, etc.
- External record consumption
- As a REST CRUD (probably require rewrite from scratch)
- GED record as endpoints allows field editing via POST/PUT
- views can default to HTML, but optionally json,csv,xml,GED,md,[your plugin here.]
- Twig!
A continuity of Webtrees forum's post. A feature request to create an API for external data manipulation of of all data structures available in Webtrees.
Key assumption here: All the business logic must be developed on API side.
Example 1: Updating single field in a single GEDCOM record of a single individual.
If you want to update a birth record then corresponding API method accepts individual's ID and new birth date and does all the magic of updating entire record on its own / on API side. That shouldn't be very hard to achieve, right? If I have individual's ID, I can:
Example 2: Linking two individuals.
I (the thin client) expect corresponding API method to expect (i.e. individual/merge) only IDs of two individuals and to do everything is needed (i.e. create a family record and update two individual records -- as you said) by itself.
If we go with the suggested approach (that entire logic should be on client-side) then we stick with a horrible assumption that this logic must be recreated (and then updated) in every connecting thin client on its own. That would be a kind of madness or the beginning of all hell -- to cite popular devs source.