@NewtonProtocol $NEWT #Newt

WENN „OPTIONAL“ NICHT IMMER OPTIONAL IST: EINE KLEINE BESONDERHEIT IM NEWTON-TASK-FLOW

Ich fand mich dabei, mehr Zeit als erwartet damit zu verbringen, darüber nachzudenken, was „optional“ in einer API wirklich bedeutet. Auf dem Papier klingt es ganz einfach. In der Praxis hängt es oft vom Kontext ab.

Das war zumindest der Eindruck, den ich bekam, als ich mir den Prozess zur Erstellung von Aufgaben in Newton ansah. Das Basisschema behandelt intent_signature als optional, doch einige Richtlinien und identity-gestützte Workflows sind weiterhin davon abhängig. Wenn diese Pfade eine gültige EIP-712-Signatur erwarten, kann das Weglassen des Felds dazu führen, dass die Anfrage fehlschlägt, bevor die Richtlinie überhaupt bewertet wird.

Zuerst dachte ich, das sei ein Widerspruch. Je mehr ich darüber nachdachte, desto mehr fühlte es sich wie eine Folge davon an, dass verschiedene Autorisierungsmodelle über denselben Endpunkt unterstützt werden. Flexibilität macht die Schnittstelle einfacher wiederverwendbar, verlagert aber auch mehr Verantwortung in die Integration.

Was ich immer noch bedenke, ist nicht das Schema selbst. Es geht darum, ob Entwickler durchgehend klar erkennen werden, welche Anforderungen vom Endpunkt kommen und welche von der Richtlinie, die sie aufrufen. Diese Unterscheidung könnte am Ende genauso wichtig sein wie die Logik der Richtlinie selbst.
#newt #NewtonProtocol
$LAB $VANRY

Newton API: Sollten „optionale“ Felder wirklich optional sein?