Sollte eine REST-API einen 500 Internal Server Error zurückgeben, um anzuzeigen, dass eine Abfrage auf ein nicht vorhandenes Objekt verweist?

39

Ich arbeite mit einer REST-API, die sich auf einem Server befindet, der Daten für eine Vielzahl von IoT-Geräten verarbeitet.

Meine Aufgabe ist es, den Server mithilfe der API abzufragen, um bestimmte Leistungsinformationen zu diesen Geräten zu erfassen.

In einem Fall erhalte ich eine Liste der verfügbaren Geräte und ihrer entsprechenden IDs und frage später den Server nach weiteren Details unter Verwendung dieser IDs (GUIDs) ab.

Der Server gibt 500 Internal Server Erroreine Abfrage für eine dieser IDs zurück. In meiner Anwendung wird eine Ausnahme ausgelöst und es werden keine Details zu dem Fehler angezeigt. Wenn ich die Antwort genauer mit Postman untersuche , kann ich feststellen, dass der Server JSON in dem Body zurückgegeben hat, der Folgendes enthält:

errorMessage: "This ID does not exist".

Ignorieren Sie zunächst die Tatsache, dass der Server die ID angegeben hat - dies ist ein separates Problem für den Entwickler.

Sollte eine REST-API ein zurückgeben, um 500 Internal Server Errorzu melden, dass eine Abfrage auf ein nicht vorhandenes Objekt verweist? Meines Erachtens sollten sich die HTTP-Antwortcodes ausschließlich auf den Status des REST-Aufrufs und nicht auf die internen Mechanismen der API beziehen. Ich würde eine 200 OKAntwort mit dem Fehler und der Beschreibung erwarten , die Eigentum der betreffenden API wäre.


Ich habe den Eindruck, dass es je nach Struktur des REST-Aufrufs einen potenziellen Unterschied in der Erwartung gibt.

Betrachten Sie diese Beispiele:

  1. http://example.com/restapi/deviceinfo?id=123
  2. http://example.com/restapi/device/123/info

Im ersten Fall wird die Geräte-ID als GET-Variable übergeben. Ein 404 oder 500 würde anzeigen, dass der Pfad ( /restapi/deviceinfo) entweder nicht gefunden wurde oder zu einem Serverfehler führte.

Im zweiten Fall ist die Geräte-ID Teil der URL. Ich würde ein besseres Verständnis haben 404 Not Found, könnte aber trotzdem darüber streiten, welche Teile des Pfades als Variablen gegenüber Endpunkten interpretiert werden.

JYelton
quelle
Wird dieser Zustand, den Sie beschreiben, als Erfolg oder Misserfolg angesehen?
Robert Harvey
@RobertHarvey Ich hatte erwartet, dass die API einige Informationen über das Gerät zurückgibt. Die Abfrage selbst sollte ein Erfolg sein, aber die fehlende Geräte-ID sollte keinen Fehler auf der Anforderungsebene verursachen.
JYelton
18
Eine nicht vorhandene ID klingt für mich wie eine 404. Der häufigste Grund für 500 Fehler sind Programmierer, die zulassen, dass eine interne Ausnahme auftritt, damit der Hosting-Server sie verarbeiten kann. Manchmal gibt es wirklich Ausnahmefälle, in denen das passiert, und manchmal ist es nur faul zu programmieren. Schwer zu sagen, was hier los ist.
Berin Loritsch
9
500 interner Server bedeutet "Es ist unsere Schuld, wir haben etwas durcheinander gebracht", und Sie sollten niemals versuchen , diesen Status an einen Benutzer zurückzugeben. Ihr Zweck ist es, im Grunde genommen einen Fehler anzuzeigen - Ihr Benutzer kann sagen, dass er eine 500 erhält, wenn er eine bestimmte Anfrage stellt, und dann können Sie hineingehen und sie beheben.
Berry120

Antworten:

96

Ich denke, eine 404-Antwort ist hier die beste semantische Übereinstimmung, da die Ressource, die Sie gesucht haben (dargestellt durch den für die Abfrage verwendeten URI), nicht gefunden wurde. Die Rückgabe einer Fehlernutzlast im Body ist sinnvoll, aber nicht erforderlich.

Gemäß RFC 2616 lautet die Definition des 404-Statuscodes:

10.4.5 404 Not Found
Der Server hat nichts gefunden, was mit dem Request-URI übereinstimmt. Es wird kein Hinweis darauf gegeben, ob der Zustand vorübergehend oder dauerhaft ist. Der Statuscode 410 (Gone) MUSS verwendet werden, wenn der Server über einen intern konfigurierbaren Mechanismus weiß, dass eine alte Ressource permanent nicht verfügbar ist und keine Weiterleitungsadresse hat. Dieser Statuscode wird häufig verwendet, wenn der Server nicht genau angeben möchte, warum die Anforderung abgelehnt wurde, oder wenn keine andere Antwort zutreffend ist.

Andy Hunt
quelle
6
404 ist nur dann eine semantische Übereinstimmung, wenn die nicht vorhandene ID der abgerufenen Ressource entspricht.
Robert Harvey
55
@ThomasOwens Eine Abfrage, die keine Ergebnisse zurückgibt, würde den Status 200 und ein leeres Array von Ergebnissen zurückgeben. Ein 404-Wert wird nur zurückgegeben, wenn eine bestimmte Objekt-ID angegeben wird, die tatsächlich nicht vorhanden ist.
Sean Burton
11
@ThomasOwens: Aus Sicht des Anrufers ist der Endpunkt nicht /questionsderselbe /questions/368213. Dieser Endpunkt ist in Ihrem Szenario nicht vorhanden. Stellen Sie sich das so vor: Wenn Sie ein GET für / foo / bar durchführen und es keinen Balken gibt, warum sollte die Antwort anders sein, wenn / foo existiert oder nicht?
Bryan Oakley
17
Richtig, es ist kein Serverfehler, wir senden also keine 5xx. Es ist ein Client-Fehler - der Client hat nach etwas gefragt, was er nicht hat, also senden wir 4xx, speziell 404.
BDSL
7
@ThomasOwens: How do you differentiate between a 404 meaning "the query returned no results" and a 404 meaning "the endpoint does not exist"?- 400 ungültige Anforderung.
Robert Harvey
34

Ich werde Ihre Beispiele verwenden.

http://example.com/restapi/deviceinfo?id=123

Wenn der Endpunkt ein json- Array zurückgibt , ist die beste Wahl für 200 OKein leeres Array, wenn kein Ergebnis gefunden wurde.

Wenn der Endpunkt ausgelegt ist , eine Rückkehr einzelnes Ergebnis , wäre meine Wahl 404 NOT FOUND, weil für mich die richtige Syntax für diese Art von Endpunkt ist: http://example.com/restapi/deviceinfo/123. Normalerweise verwende ich den Anforderungsparameter nur zum Filtern und wenn mein Endpunkt ein Array zurückgibt.

http://example.com/restapi/device/123/info

Ich denke , diese Frage wurde bereits beantwortet hier . POST oder GET, die bessere Wahl scheint, 404 NOT FOUNDweil die Ressource 123nicht gefunden wurde.

In beiden Fällen sehe ich nicht die Notwendigkeit, den Grund für die Anfrage zu erklären, wurde nicht abgeschlossen. Die Anforderungsinformationen und der HTTP-Code erklären bereits, warum.

Dherik
quelle
2
Wie unterscheidet man eine nicht vorhandene ID von einer ungültigen URL?
Robert Harvey
2
@luizfzs, das kannst du auch, da sehe ich kein Problem. In einigen APIs, die ich entwickelt habe, bevorzuge ich die Verwendung von 204 in einem erfolgreichen PUT oder DELETE ( wie hier erläutert ), ohne dass ein Body bei der Antwort angezeigt wird.
Dherik
10
Warum sollten Sie auf dieser Ebene zwischen einer nicht vorhandenen ID und einer ungültigen URL unterscheiden? In beiden Fällen stellen Sie immer noch eine gültige Anfrage, was HTTP betrifft. Der Server kann die Ressource, die Sie ansprechen, einfach nicht finden . Eine fehlerhafte URL ist keine fehlerhafte Anfrage. es ist eine wohlgeformte Bitte um das Falsche .
CHAO
6
@cHao Weil ich als Entwickler wissen möchte, ob meine App fehlschlägt, weil das Element nicht vorhanden ist, oder ob ich meine App versehentlich auf app.company.cxm / test / und nicht auf app.company.cxm / tst / verwiesen habe.
Patrick M
7
@PatrickM: Als Entwickler sollten Sie wissen, dass Fehlerantworten auch einen Nachrichtentext enthalten können. Hier finden Sie erklärende Fehlerinformationen, wenn Sie es wirklich wollen. Brechen Sie nicht die Semantik, nur weil Sie paranoid sind in Bezug auf dicke Finger. Auf der HTTP-Ebene spielt es keine Rolle, ob Sie wie /itms/1234oder durcheinander gebracht haben /items/12234.
CHAO
27

HTTP 404 ist korrekt, da der Server versteht, nach welcher Ressource der Client fragt, diese Ressource jedoch nicht hat.

Die Tatsache, dass Sie mit einer "REST-API" arbeiten, ist der Schlüssel. Die API sollte sich so verhalten, als würde sie eine REpresentational State Transfer durchführen und keine Funktion ausführen. (Sicher, der Begriff "REST" hat eine breitere Bedeutung erhalten, aber Sie können seine wörtliche Bedeutung auch hier sinnvoll verwenden.) Der Client hat nach dem Status einer durch die URL beschriebenen Ressource gefragt http://example.com/restapi/device/123/info. Ein Querystring ( /deviceinfo?id=123) würde die Situation nicht ändern. Der Server weiß, dass Sie den Status von Gerät 123 übertragen möchten, erkennt dies jedoch nicht als bekannte Ressource. Daher HTTP 404.

Die anderen möglichen Antworten, die hier diskutiert werden, haben ebenfalls spezifische Bedeutungen:

  • HTTP 200- Wir haben den Staat für Sie; Es ist im Antworttext.
  • HTTP 204- Wir haben den Staat für Sie; es ist leer.
  • HTTP 400- Wir können nicht sagen, nach welcher Ressource Sie fragen. Korrigieren Sie Ihre URL.
  • HTTP 500- Wir haben versagt. Nicht deine Schuld.

Siehe RFC 2616 Sec. 10 entsprechend.

Travis Wilson
quelle
Ich bin damit einverstanden. Wenn der Server eine 404 zurückgeben würde, wäre dies sinnvoller als das, was er tut (eine 500). Danke.
JYelton
11

Ein 5xx-Fehler wird normalerweise verwendet, um anzuzeigen, dass der Server einen Fehler festgestellt hat und die Anforderung nicht ausführen kann. Wenn der Server die Anforderung entgegennimmt, sie erfolgreich analysieren kann und dann seine Arbeit tut, sollte dies keinen 5xx-Fehler zurückgeben.

Ich bin mir nicht sicher, ob es irgendeine Konvention gibt, was zurückgegeben werden soll, wenn eine Abfrage keine Ergebnisse liefert. Ich habe sowohl das gesehen, was Sie beschreiben (200 mit einem Körper, der eine Nachricht enthält), als auch einen 404, der angibt, dass keine Ergebnisse gefunden wurden. Die 200 ist wahrscheinlich am sinnvollsten - die Anforderung wurde erfolgreich ausgeführt, und es gab keine Probleme mit der Anforderung des Clients oder während der Verarbeitung der Anforderung durch den Server. Ein Body kann eine Nachricht an den Client übermitteln.


Ich würde beide Beispiele ( http://example.com/restapi/deviceinfo?id=123und http://example.com/restapi/device/123/info) gleich behandeln - das 123ist ein Parameter. In beiden Fällen gibt es verschiedene Möglichkeiten, eine Anforderung zum Abrufen von Geräteinformationen für ein Gerät mit der ID 123 zu strukturieren.

Zunächst würde ich Autorisierung und Authentifizierung in Betracht ziehen. Wenn der Benutzer nicht über die entsprechenden Berechtigungen verfügt, würde ich eine 403 oder eine 401 entsprechend zurückgeben. Obwohl es als "nicht autorisiert" bezeichnet wird, handelt es sich nach meinem Verständnis bei 401 mehr um Authentifizierung und bei 403 um nicht autorisiert oder um die Verweigerung von Berechtigungen. Ich wäre hier jedoch nicht zu wählerisch, wenn Sie sich nur für alle Authentifizierungs- und Autorisierungsfehler an 403 halten möchten.

Dann würde ich die ID behandeln. Basierend auf Ihrem Beispiel sieht es so aus, als wäre es eine numerische ID. Wenn ein nicht numerischer Wert angegeben würde, würde ich eine 400 zurückgeben. Wenn der Parameter möglicherweise eine gültige Gerätekennung sein könnte, würde ich mit der Verarbeitung fortfahren. Wenn es andere Argumente gäbe, würden sie auch hier überprüft. Ich würde erwarten, dass der Antworttext angemessene Informationen darüber enthält, warum die Anfrage schlecht war.

Wenn alle Parameter gültig wären, würde ich mit der Verarbeitung der Anfrage beginnen. Wenn das System oder eine Abhängigkeit (eine Datenbank, ein Drittanbieter-Service, ein anderer interner Service) nicht verfügbar ist, würde ich einen 5xx-Code zurückgeben - 503 wäre spezifisch, aber 500 wäre auch akzeptabel. In jedem Fall würde ich eine Leiche mit zusätzlichen Details zurückgeben. Beachten Sie, dass, wenn eine externe Abhängigkeit ein 408-Anforderungs-Timeout meldet, ich das esse und eine 500 an meinen Client zurückgebe, sodass ein Client nur dann eine 408 erhalten kann, wenn die Anforderung an mein System abgelaufen ist. Wenn das System in der Lage ist, die Anfrage zu vervollständigen, würde ich eine 200 und die entsprechende Stelle zurückgeben.

204 kann in einigen Fällen hilfreich sein, hindert Sie jedoch daran, einen Antworttext zu senden. Insbesondere in einer API-Einstellung erscheint es in den meisten Fällen als die richtige Entscheidung, einen Antworttext mit Informationen zu senden, die in einen Protokollierungs- oder Berichtsmechanismus eingegeben werden können.

Das einzige Mal, dass ein 404 zurückgegeben wird, ist, wenn der Server keinen /deviceinfoEndpunkt oder keinen /device/:id/infoEndpunkt hat.

Ich würde eine ID, die nicht gefunden wird, nicht als dieselbe wie die nicht gefundene Ressource betrachten. Die Ressource ist die Geräteinformation für ein bestimmtes Gerät (in Ihrem Beispiel). Die Rückgabe eines 404 würde bedeuten, dass die Ressource (die Geräteinformationen) nicht vorhanden ist. Ein 200 mit einem geeigneten Körper bedeutet, dass das System tatsächlich Geräteinformationen bereitstellen kann. Möglicherweise ist ein Gerät mit der angegebenen ID vorhanden oder nicht.

Thomas Owens
quelle
1
@RobertHarvey Ja. Es gab keine Fehler. Nur weil der Server die GUID generiert und an den Client gesendet hat, bedeutet dies nicht, dass sie von einem anderen Vorgang entfernt wurde. Die Anfrage / Antwort war erfolgreich. Der Befehl oder die Abfrage, die von der Anforderung dargestellt werden, haben keine Daten zurückgegeben. Für mich ist das kein Misserfolg. Es könnte eine Ausnahme sein, aber ich bin nicht überzeugt, dass dies einen 5xx wert ist.
Thomas Owens
2
Wenn ich diese von mir abgefragte API entwerfen würde, müsste sie 200 mit einem Body zurückgeben, der dann etwas zum Effekt von enthält device: 123; status: not found;. Dann weiß ich, dass die Abfrage funktioniert hat und dass die API mir nützliche Informationen liefert.
JYelton
7
@Blrfl Das wird durch den Wortlaut vieler Websites mit 500 Seiten belegt (wenn auch nicht "bewiesen"), normalerweise durch "Wir haben einen Fehler gemacht und werden nachforschen". Meiner Meinung nach sendet ein ordnungsgemäß funktionierender Server niemals 500s, außer vielleicht bei kosmischen Strahlen.
Mbrig
6
HTTP hat kein Konzept eines "Endpunkts", keine relevante Unterscheidung zwischen einer Variablen und dem Rest der URL, und daher ruht auch keine. Möglicherweise verfügen Sie über ein Routing-System, das mit einem regulären Ausdruck übereinstimmt und Tausende von URLs an eine Controller-Funktion weiterleitet. Dies ist jedoch ein Implementierungsdetail und kein grundlegender Bestandteil der API. Eine Antwort von 200 auf einen Abruf gilt nur für den Fall, dass die angeforderte Ressource abgerufen wird. In diesem Fall möchte der Client eine Darstellung einer nicht vorhandenen Ressource, daher ist 404 die richtige Antwort.
BDSL
8
Ein ordnungsgemäß funktionierendes System sendet niemals 500 Antworten. Ein ordnungsgemäß funktionierender Server kann eine 500 senden, da, wenn er Teil eines größeren Systems ist und einen internen Fehler in diesem größeren System festgestellt hat, z.
BDSL
5

Ein HTTP-Fehler der 500er-Serie weist auf eine Fehlfunktion des Servers hin. Abgesehen von 501 Not Implementedund 505 HTTP Version Not Supportedhat die Verwendung dieser Fehlercodes die Implikation, dass ein erneuter Versuch der Anforderung zu einem späteren Zeitpunkt erfolgreich sein kann (obwohl dies nur 503 Service Unavailableexplizit angegeben wird). Im Idealfall sollte ein Server niemals einen dieser Codes produzieren, obwohl die Unfähigkeit, fehlerfreie Software zu schreiben und den Server mit unendlichen Ressourcen auszustatten, bedeutet, dass Sie diese von Zeit zu Zeit benötigen.

Für ein "Objekt existiert nicht" -Ergebnis sollten Sie wahrscheinlich entweder 404 Not Found(wenn die Anforderung ein Objekt nach Namen enthält) oder 200 Successeinen leeren Ergebnistext (wenn Sie ein Objekt nach Attributen suchen) zurückgeben. 204 No Contentsieht verlockend aus, aber ich würde es nur in Situationen verwenden, in denen das Fehlen eines Antwortkörpers das erwartete Ergebnis ist.

Kennzeichen
quelle
1

Wenn ich als Client Ihrer API einen der folgenden Aufrufe vornehme:

  1. http://example.com/restapi/deviceinfo?id=123
  2. http://example.com/restapi/device/123/info

Ich erwarte, dass ich ein (Repräsentations-) DeviceInfoObjekt zurückerhalte (oder auf jeden Fall einen bestimmten Typ, egal ob es sich um einen formalen Typ handelt oder nur um etwas, das einer dokumentierten "Ententyp" -Konvention entspricht). Ich möchte, dass ein 200Status bedeutet, dass ich tatsächlich einen habe, und ich kann fortfahren und ihn verwenden.

Für REST-APIs stelle ich mir 400 und 500 Statuscodes als Ausnahmen vor. Sie geben damit an, wann Sie keine "normale" Antwort auf die von Ihnen empfangene Anfrage zurückgeben können. Der Client muss also etwas Außergewöhnliches tun, anstatt die erwarteten Informationen zu verarbeiten.

Dies bedeutet, dass ich als API-Konsument eine Art Checked-Rest-Call-Funktion verwenden kann, die eine Antwort abruft oder eine Ausnahme auslöst. Das ist großartig; Meine normale Logik kann linearer Code sein, und ich kann meine Fehlerbehandlung so organisieren, wie ich es im lokalen Code tue. Unerwartete 404-Werte werden als "Keine Ressource gefunden" -Ausnahmen angezeigt, ohne dass ich etwas tun muss, und nicht als "Fehlende Attribute" -Fehler, wenn ich später verarbeite, { errorMessage: "Device 123 not found" }als wäre es ein DeviceInfoObjekt.

Wenn Sie Grund , dass der Endpunkt http://example.com/restapi/deviceinfo wird gefunden, und es ist nur die , id=123die nicht, und so zurückkehren 200 mit einer Fehlermeldung im Körper, dann bist du zu schaffen genau die gleiche Art von Schnittstellenproblemen als C - Funktionen , die entweder einer Rückkehr könnten Richtiges Ergebnis oder ein Fehlercode oder Methoden, die Probleme durch willkürliche Rückgabe anzeigennull. Als Benutzer Ihrer Benutzeroberfläche ist es viel angenehmer, Fehler durch einen "separaten" Kanal von regulären Rücksendungen anzeigen zu lassen. Dies gilt auch hier, obwohl HTTP-200-, HTTP-404- und HTTP-500-Antworten aus der Sicht einer niedrigen Ebene der gleiche Kanal sind. Sie sind standardisiert und leicht zu unterscheiden, sodass mein REST-Client-Framework diese Status problemlos aktivieren kann, um sie in die richtigen Strukturen in meiner Sprache umzuwandeln. Um dasselbe mit der JSON-Ebene zu tun (wo Sie immer 200 sagen und mir entweder eine DeviceInfooder eine Fehlermeldung geben), muss ich einige Kenntnisse über die von Ihnen verwendeten JSON-Schemas einbetten.

Verwenden Sie daher nur 200, wenn Sie einen gültigen Wert des erwarteten Typs zurückgeben können (daher http://example.com/restapi/search-devices?colour=bluekann 200 mit einem leeren Array zurückgegeben werden, wenn keine blauen Geräte vorhanden sind; ein leeres Array ist ein gültiges Array und eine sinnvolle Antwort auf die Anforderung "I möchte die details aller blauen geräte "). Wenn dies nicht möglich ist, verwenden Sie den am besten geeigneten Nicht-200-Statuscode. Auch wenn "Gerät 123 nicht vorhanden" die richtige Antwort auf "Geben Sie mir die Details von Gerät 123" ist und kein Fehler für den Server darstellt , ist dies eine Ausnahme für die Erwartung des Clients, dass er ein zurückerhält DeviceInfound sollte nicht wie gewohnt kommuniziert werden "hier ist das, wonach du gefragt hast" antwort.

Ben
quelle
Leider bin ich auch Kunde dieser API und kann sie nicht ändern. Dies ist eine große Zusammenfassung, wie es sollte funktionieren, wenn.
JYelton
0

Sie könnten Fehler 422 Unprocessable Entity verwenden, um zu unterscheiden, dass 404 nicht gefunden wurde . 422 bedeutet, dass der Server die Anforderung versteht, aber keine ordnungsgemäße Antwort geben kann. Ich verwende diesen Code in ähnlichen Situationen.

FiNeX
quelle
4
In diesem Artikel wird die Verwendung von 422 ausführlicher beschrieben. Ich denke nicht, dass dieser Fehlercode hier wirklich anwendbar ist.
Robert Harvey
Danke, sehr nützlich! Ich werde dieses Thema vertiefen müssen!
FiNeX
0

Fehler 500 zeigt normalerweise an, dass die Anforderung ein serverseitiges Programm zum Absturz gebracht hat. In Unternehmensumgebungen werden diese Fehler wie ein Ei im Gesicht behandelt und vermieden.

Fehler 4xx sollte dem Programmierer signalisieren, dass der API-Endpunkt (Ressource) nicht vorhanden ist. Sobald der entsprechende Endpunkt erreicht ist, liegt die Fehlerbehandlung ab diesem Zeitpunkt in der Verantwortung des Programmierers der API, die ordnungsgemäß behandelt werden sollte, dh mit einer Fehlermeldung von 200 Antworten.

postronnim
quelle
1
Sie sagen also "Verwenden Sie 500 nicht, weil Sie den Server nicht zum Absturz bringen?"
Robert Harvey
0

Obwohl das w3 feststellt, dass 404 verwendet wird, wenn keine andere Antwort zutreffend ist , ist dies nicht das, wofür eine 204-Antwort (ohne Inhalt) gut ist? Die Anforderung war vom Verarbeitungsstandpunkt aus gültig, und der Server hat die Anforderung verarbeitet und hat ein Ergebnis. Das ist ein Erfolg, der sich zu 2xx Antworten neigt. Es gab keinen Inhalt für diese bestimmte Anfrage, so dass 204 dem Benutzer mitteilt, dass an seiner Abfrage nichts falsch war, aber nichts da ist.

Sie könnten auch einen schwachen Fall machen, dass 409 (Konflikt) eine angemessene Antwort ist. Obwohl 409 am häufigsten für einen POST verwendet wird, heißt es doch

Die Anforderung konnte aufgrund eines Konflikts mit dem aktuellen Status der Ressource nicht abgeschlossen werden. Dieser Code ist nur in Situationen zulässig, in denen erwartet wird, dass der Benutzer den Konflikt möglicherweise lösen und die Anforderung erneut senden kann. Der Antworttext SOLLTE genügend Informationen enthalten, damit der Benutzer die Ursache des Konflikts erkennen kann. Im Idealfall würde die Antwortentität genügend Informationen enthalten, damit der Benutzer oder Benutzeragent das Problem beheben kann. Dies ist jedoch möglicherweise nicht möglich und nicht erforderlich.

Das Nichtvorhandensein der angeforderten ID ist hier möglicherweise der Konflikt, und die Meldung, dass keine solche ID im System vorhanden ist, reicht aus, um den Konflikt zu erkennen und zu beheben.

Geld
quelle
3
Nein, eine Antwort auf eine Abrufanforderung wäre nur dann sinnvoll, wenn die angeforderte Ressource gefunden wurde und ihre Darstellung genau null Zeichen lang ist.
BDSL
0

Die anderen Antworten befassen sich damit, aber ich wollte nur darauf hinweisen, dass ein Fehler der 500er-Serie bedeutet, dass ich etwas durcheinander gebracht habe. In diesem Fall bedeutet "I" die API, also einen unbehandelten Serverfehler oder ähnliches. Ein Fehler der 400er-Serie bedeutet "Sie haben etwas durcheinander gebracht" - der Aufrufer der API hat etwas Falsches gesendet.

Marcie
quelle
-4

Andere Benutzer haben gültige Antworten gegeben, um herauszufinden, was zu tun ist, wenn Sie das Buch lesen möchten.

Ich würde jedoch vorschlagen, dass Sie zu viel in die RESTfulness lesen und absolut koscher in Bezug darauf sind.

REST ist ein launisches Protokoll, denn wenn Sie das Buch während der Verwendung durchgehen möchten, müssen sowohl Client als auch Server mit spezifischem Wissen über die Tatsache erstellt werden, dass sie über REST kommunizieren, was im Wesentlichen das spezifische Kommunikationsprotokoll ist used kann nicht abstrahiert werden.

Es gibt einen anderen Ansatz: Vermeiden Sie RESTfulness vollständig und verwenden Sie es nur als Kommunikationsprotokoll und sonst nichts. Dies bedeutet, dass die einzigen Antworten, die zurückgegeben werden müssen, "HTTP 200 OK" und "HTTP 500 Internal Server Error" sind, da hinsichtlich des Kommunikationsprotokolls jeder Kommunikationsversuch nur zwei Ergebnisse haben kann: Entweder war die Anforderung erfolgreich an den Server geliefert oder nicht.

Was nach der Auslieferung passiert, geht das Kommunikationsprotokoll nichts an. Nachdem der Server die Anforderung erfolgreich empfangen und mit der Verarbeitung begonnen hat, können viele Fehler auftreten. Dies sind jedoch alle anwendungsspezifischen Fehler, über die das Kommunikationsprotokoll nichts zu wissen hat. Sie sollten innerhalb der Nutzlast einer Antwort kommuniziert werden, die nach Kenntnis des Kommunikationsprotokolls vollkommen erfolgreich aussieht.

Unterm Strich würde ich also empfehlen, "HTTP 200 OK" zurückzugeben und in der Antwortnutzlast ("Antwortinhaltshauptteil" in der HTTP-Sprache) einen anwendungsspezifischen Fehlercode mit der Aufschrift "ID nicht gefunden" oder was auch immer zu verwenden.

Mike Nakis
quelle
Den Abstimmungen nach zu urteilen, muss ich die Gefühle einiger Leute verletzt haben. Oder vielleicht ein anderer Teil ihres Körpers. C -: =
Mike Nakis
Sie sollten dies unbedingt
Mike Nakis
1
Hier ist nichts passiert. Du liegst einfach falsch. Sogar in dem Artikel, auf den Sie verlinkt haben, wird die Verwendung von Statuscodes nicht so offensichtlich erwähnt, dass Fehler und Erfolg gleich aussehen. Es heißt: "Apropos Geschmack, es ist wichtig, sich daran zu erinnern, dass API-Design nicht ausschließlich die praktischen Auswirkungen auf Client- und Server-Software betrifft. Die Zielgruppe für eine API ist der Entwickler, der sie konsumieren wird. Nach dem" Prinzip der Mindestens " Erstaunen: "Entwickler werden es leichter haben, eine API zu lernen und zu verstehen, wenn sie denselben Konventionen folgt wie andere APIs, mit denen sie vertraut sind."
CHAO
@cHao also, ich nehme an, der Teil, der besagt "Dropbox verwendet derzeit ungefähr 10 verschiedene Statuscodes (8 Fehler und 2 für den Erfolg), aber wir planen, diese Anzahl in einer zukünftigen Version der API zu reduzieren", hatte nichts damit zu tun Sie.
Mike Nakis
Meinte nicht, was du davon bekommst. Wenn sie wissen, was sie tun, reduzieren sie dies im Extremfall auf einen Erfolg und vier Fehlercodes (400, 401, 404 und 500), da sie sich offensichtlich für Konventionen interessieren.
CHAO