Business-Logik und RESTful API Design

Question

Nehmen wir an, wir eine einfache API ermöglicht Kunden eine Liste von Elementen eines bestimmten Typs zu holen:

GET /items/foo 
    GET /items/bar 
    GET /items/blah 

Eine Antwort ist eine Liste der Elemente des angeforderten Typs, wobei jeder Eintrag hat eine eindeutige ID. Der Client zeigt diese Einträge normalerweise in Tabelle/Grid/etc an.

Jetzt im Client müssen wir eine Pinning-Funktion implementieren, so dass eine andere API das Pinnen/Lösen von Elementen basierend auf ihrer ID & ihres Typs ermöglicht. Also habe ich mit meinen Kollegen Möglichkeiten besprochen, um den Kunden darüber zu informieren, welche Artikel fixiert sind oder nicht.

Eine Option war eine andere API GET /pinning/{type}, um die Liste aller angehefteten Elemente eines bestimmten Typs zurückzugeben.

Eine andere Lösung bestand darin, eine ähnliche API GET /pinning/{type} zu verwenden, um die Liste der IDs aller fixierten Elemente zurückzugeben. Lassen Sie den Kunden es aussortieren.

Die erste Lösung wurde akzeptiert. Ihr Argument war, dass das Backend für die Geschäftslogik verantwortlich ist und dass der Client nicht an der Geschäftslogik beteiligt sein sollte, so dass der Client nur Daten anzeigen sollte, die er vom Server erhält. Dieses Argument verkaufte es nicht für mich. Ich denke, der Server sollte in diesem Fall die Daten bereitstellen, die es dem Client ermöglichen, zusätzliche Präsentationslogik durchzuführen.

Welche Lösung ist besser? Oder welche anderen Lösungen sind möglich?

Answer 1

Wenn der Server ItemIds nur unter GET /pinning/{type} zurückgibt, müsste der Client wiederholt so etwas wie GET /items/{itemId} aufrufen, um Daten zu erhalten, die auf der Benutzeroberfläche angezeigt werden können, richtig? Dies würde wiederum die Belastung des Servers erhöhen. Wenn die ID ausreichen würde, können Sie wahrscheinlich mit der vorgeschlagenen Lösung durchkommen. Da sowohl der Client als auch der Server unter dem gleichen Dach zu stehen scheinen (wie in Ihrem Unternehmen ist auch der API-Verbraucher), haben Sie genügend Informationen, um eine Entscheidung zu treffen.

Selbst wenn es eine öffentliche API mit vielen Clients wäre, würde ich immer noch die Route der Rückgabe von Elementen anstelle von nur ItemIds gehen - wahrscheinlich in einer seitenweisen Weise, aus Leistungsgründen.