Vereinfachung der Objekt API #4
Conversation
die eigenschaften children, parents und root sind ja sehr teuer. ob sie für eine konkrete fragestellung im user client gebraucht werden ist offen. durch ein caching des clients sollte das performant bleiben. es ermöglicht auch das asynchrone laden eines teilgraphen.
GET ist wohl doch das vernünftigste, schon zum cachen. ansonsten sollten die vorschläge selbsterklärend sein.
|
|
||
| - method: `GET` | ||
|
|
||
| Man gibt zusaetzlich zur **26**-stelligen (:point_up:) ID noch den namen der eigenschaft an, die man haben will. Moeglich sind `name`, `type`, `roots`, `parents`, `children`. Bei einem der letzten drei erhaelt man eine JSON response mit einer liste (ein eintrag kann mehrere wurzelelemente haben) von objekten mit jeweils `id`, `type` und `name` der verwandten thesauruseintraege. Wenn man `name` oder `type` anfragt, bekommt man eine `text/plain` response wo nur der gewuenschte inhalt drin steht. |
There was a problem hiding this comment.
Bist Du sicher dasz aufloesen von IDs direkt nach name und type nicht praktisch waere? Das wird ja jedesmal passieren wenn die GUI eine ths-ID in irgendeinem feld darstellen soll.
There was a problem hiding this comment.
mein eindruck war, dass die ersten beiden endpunkte redundantes zurück liefern. also, ich kriege ne liste der kinder, inklusive type und name. im cache könnte das aber schon von einer abfrage des objekts her bekannt sein.
oder so: der zweite endpoint ist als vertiefende ergänzung des ersten zu verstehen. der use-case type von diesem endpunkt zu verarbeiten wäre ja wohl ein filtern. das ergänze ich mal als parameter.
README.md
Outdated
|
|
||
| ```json | ||
| [ | ||
| "https://tla.bbaw.de/ths/get/CLJN6LLO5NDL7DY6HOP4XC4ELE", |
There was a problem hiding this comment.
Waere es nicht sinnvoller, hier gleich name und type dazu zu bekommen und nicht fuer jedes ergebnis noch einen request absetzen zu muessen? Gegenwaertig sieht die ausgabe einer solchen anfrage so aus:
http://tladev.bbaw.de:5002/ths/get/LCMP3D4CMZDLBPCVAH6VV5LCJQ/parents[
{
"id": "SFMJKLYBONEOVPSZ5BYZEMR5OE",
"name": "Boeser, Pieter Adriaan Aart",
"type": "person"
},
{
"id": "GHGBEBH62ZFPRFF5ELA4EZTKCI",
"name": "36 = Bibliographie",
"type": "bibliography"
}
]soll ich so lassen oder echt nur URLs zurueckgeben?
There was a problem hiding this comment.
eigentlich ist nur roots teuer, und children kann halt sehr lang sein (bei bibliography und person). Ich hatte vorgesehen, bei abfrage von nur children/parents (ueber ths/get/<ID>/children bzw parents) nicht nur die ID oder URL fuer jedes item ausgeben, sondern auch gleich name und type, um die information ohne weitere requests parat zu haben. Aber tatsaechlich sind wir ja gar nicht sicher ob wir das brauchen.
die überlegung kam daher, dass du meintest, dass da auch mal 100 children dran hängen könnten. das ist auch client-seitig in den meisten situationen eher overkill, in denen eine solche sparse response reicht.
das sollte der cache am client leisten!?
eben, deswegen lieber erstmal straight und simpel. bei bedarf lässt sich ja dann noch erweitern. (zb. ein |
This comment has been minimized.
This comment has been minimized.
eigentlich kann auch das ein kompromiss sein, um design-inkonsistenzen in der zukunft zu vermeiden (jetz: liste von strings, später evtl.: liste von mappings). also die |
This comment has been minimized.
This comment has been minimized.
| } | ||
| ``` | ||
|
|
||
|
|
||
| im falle eines fehlers steht im `result`-feld der response `{"total": 0, "offset": 0,"objects": []}`. |
There was a problem hiding this comment.
objects, weil {"result": {"results": […]}} mir error-prone scheint.
| @@ -25,14 +25,13 @@ Man gibt die **26**-stellige (:point_up:) ID des thesauruseintrags an und bekomm | |||
| Man gibt zusaetzlich zur **26**-stelligen (:point_up:) ID noch den namen der beziehung | |||
| an, deren objekte man haben will. Moeglich sind `roots`, `parents` und `children`. Man erhält | |||
| eine JSON response mit einer liste (ein eintrag kann mehrere wurzelelemente haben) von URLs | |||
| von objekten. | |||
| von objekten. Wie im endpoint `search` kann der parameter `type` zum filtern angegeben werden. | |||
There was a problem hiding this comment.
Was soll denn das bringen?
There was a problem hiding this comment.
na, du merktest ja richtig an, dass es situationen geben könnte, in denen zb <id>/children gleich namen und type mit liefern könnte. eine naheliegende wäre nme das filtern nach type.
einen konkreten use-case habe ich nicht. ich bin da leidenschaftslos.
|
dieser neue "Resolve conservation" button is übrigens sehr hilfreich, um übersichtlichkeit herzustellen. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
okay, bei dem error abschnitt bin ich etwas zurückhaltend. ergänz einfach. und ja, egal welche antwort kommt, es wird nicht ge sonst ist mir noch die frage nach dem |
funkyfuture
force-pushed
the
api-kritik
branch
from
675abaa
to
3cf1282
Compare
ich push hier mal sukzessive commits rein. meinetwegen können wir die, die diskussionsunwürdig sind, direkt in den
mastercherry-picken.erörterungen sind in den commit messages.
ich wrappe bei 89 chars, weil black das so macht und black hat immer recht, wenn es um mergability geht.