it-swarm.com.de

Best Practice für REST API-Aufruf mit vielen Parametern

Ich habe eine REST API mit GETs-Operationen, die eine (lange) Liste von Parametern erhalten (z. B. 8 Parameter). Das Ziel dieser Operation ist das Suchen und Filtern von Elementen.

Welches ist die beste Vorgehensweise, um dieses Szenario zu verwalten?:

(1) Liste erhalten von Parametern?:

public ResultType Get(int p1, int p2, string p3...) { ... }

(2) Oder erhalten Sie ein Objekt, das diese Parameter kapselt?:

public class MyClass
{
    public int X { get; set; }
    public int Y { get; set; }
    public string Z { get; set; }
}

public ResultType Get(MyClass parameter) { ... }

Denken Sie an ein E-Commerce-Szenario, in dem Sie "Produkte" nach Name, Beschreibung, Kategorie, Marke, Modell, Preis usw. suchen und filtern möchten.

11

Ich habe eine REST API mit GETs-Operationen, die eine (lange) Liste von> Parametern erhalten. Welches ist die beste Vorgehensweise, um dieses Szenario zu verwalten?

AFAIK, es gibt keine fest etablierten Best Practices (sorry). Man kann jedoch einige Empfehlungen aussprechen:

  • Versuchen Sie zu vermeiden, POST (anstelle von GET) zu verwenden, wenn die Anforderung safe (dh nebenwirkungsfrei, insbesondere ohne Datenänderung). Wenn die Parameter sehr groß sind, müssen Sie möglicherweise POST verwenden, um Längenbeschränkungen zu umgehen. In der Regel ist dies jedoch kein Problem (die meisten Programme unterstützen recht lange URLs), und sichere Anforderungen sollten GET, um Optimierungen wie Caching und Prefetching zu ermöglichen.

  • Wenn Sie GET verwenden, müssen Sie Ihre Parameter als URL-Parameter senden1). In dieser Situation besteht die natürliche und übliche Lösung darin, eine Liste von Parametern zu verwenden. Daher würde ich dies empfehlen. Ja, die Liste wird lang sein, aber die API REST) ist (wahrscheinlich) für die programmatische Verwendung vorgesehen, daher sehe ich kein Problem damit. Benutzer der API können die API frei kapseln Parameter in einem Objekt innerhalb ihres eigenen Codes.

  • Technisch gesehen könnten Sie auch ein Objekt in einen URL-Parameter einfügen (als JSON, XML oder was auch immer), aber das ist ungewöhnlich, also würde ich es vermeiden, wenn möglich.

1) Genau genommen können Sie einen Body mit einer GET -Anforderung verwenden, dies ist jedoch ungewöhnlich und wird im Allgemeinen nicht empfohlen. siehe z.B. HTTP GET mit Anforderungshauptteil .


Genau wie bei Methoden im Quellcode mit langen Parameterlisten möchten Sie möglicherweise prüfen, ob die API REST] ein Refactoring benötigt. Genau wie im Quellcode gibt eine so lange Parameterliste das an Der API-Endpunkt macht viele verschiedene Dinge. Ist es vielleicht sinnvoll, ihn aufzuteilen oder Standardeinstellungen bereitzustellen? Aber das ist eine andere Frage ...

10
sleske

Best Practice ist es, POST die Parameter als Objekt.

Dadurch werden die URL-Längenbeschränkung und andere Probleme mit Abfragezeichenfolgen vermieden. Wenn Sie mehrere Parameter in JSON senden, ist ein Objekt die Standardmethode. Daher ist es sinnvoll, auf einen zu deserialisieren.

Sie können vermeiden, zufällige Anforderungsobjekte zu erstellen, die nur in Ihren Controllern verwendet werden, indem Sie auf Wunsch zu einem dynamischen Objekt deserialisieren. obwohl das anschließende Casting auf die richtigen Typen ebenso chaotisch sein kann.

Früher war es möglich, dass mehrere Parameter in Ihrer Controller-Aktion automatisch an die Felder eines eingehenden JSON-Objekts gebunden wurden. Dies funktioniert jedoch nicht mehr sofort im .net-Kern.

Obwohl es dies gibt, könnte ich versucht sein, es zu versuchen

https://docs.Microsoft.com/en-us/aspnet/core/mvc/controllers/application-model?view=aspnetcore-2.1#application-model-usage-in-webapicompatshim

Bearbeiten: Ich werde nur ein paar Punkte zur Verwendung von GET hinzufügen

  • Caching: GET wird von Clients zwischengespeichert, die der HTTP-Spezifikation entsprechen. Die Spezifikation soll jedoch das Laden von Webseiten beschleunigen. Das Caching ist hilfreich, wenn Ihr API-Ergebnis dieselben Cache-Anforderungen wie eine Webseite hat, aber nicht hilfreich, wenn dies nicht der Fall ist. Sie können bei Bedarf Ihr eigenes Caching von POST Antworten im Client hinzufügen).

  • URL-Länge: Dies ist hauptsächlich ein Problem, wenn Sie ein Array senden. Offensichtlich kann ein Array leicht sehr lang werden und die Parameternamen der Abfragezeichenfolge werden für jedes Element wiederholt. Selbst wenn Sie nur eine Zeichenfolge senden, kann diese Zeichenfolge technisch gesehen sehr, sehr lang sein.

  • Protokollierung: Standardmäßig protokollieren viele Webserver die gesamte Abfragezeichenfolge. Oft möchten Sie nicht, dass Parameterdaten in Nur-Text-Protokollen landen.

  • GET with body: Dies scheint die perfekte Antwort zu sein, die REST Puristen befriedigt und gleichzeitig eine schöne Datenstruktur zulässt, aber es ist ungewöhnlich und verpönt, a POST) = ist die Standardmethode zum Senden eines Körpers.

2
Ewan