Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite sind die Ausnahmen aufgelistet, die von der endpoints-Bibliothek zur Verfügung gestellt werden, sowie die von Cloud Endpoints Frameworks unterstützten HTTP-Statuscodes.
In vielen Situationen möchten Sie vielleicht gängige HTTP-Statuscodes verwenden, um einem Nutzer anzuzeigen, ob seine API-Anfrage erfolgreich war oder nicht. Wenn ein Nutzer beispielsweise versucht, eine nicht vorhandene Entität abzurufen, können Sie einen HTTP-404-Statuscode senden und damit mitteilen, dass keine Entität mit der ID entityIdvorhanden ist.
Zum Senden gängiger HTTP-Statuscodes können Sie wie folgt eine von der endpoints-Bibliothek bereitgestellte Ausnahme auslösen:
thrownewNotFoundException(user.getEmail());
Von Endpoints Frameworks ausgegebene Ausnahmen
Endpoints Frameworks gibt die folgenden Ausnahmen aus. Diese entsprechen spezifischen HTTP-Statuscodes:
Cloud Endpoints Frameworks unterstützt in API-Antworten einen Teil der HTTP-Statuscodes. Die unterstützten Codes werden in der folgenden Tabelle beschrieben.
HTTP-Statuscodes
Unterstützung
HTTP 2xx
Endpoints Frameworks geht bei einer erfolgreichen Rückgabe der API-Methode normalerweise von HTTP 200 aus. Wenn der Antworttyp der API-Methode void oder der Rückgabewert der API-Methode null ist, wird stattdessen HTTP 204 festgelegt.
HTTP 3xx
HTTP 3xx-Codes werden nicht unterstützt. Bei der Verwendung von HTTP 3xx-Codes wird HTTP 404 zurückgegeben.
HTTP 4xx
Es werden nur die folgenden HTTP 4xx-Codes unterstützt:
400
401
403
404
409
410
412
413
Für alle anderen HTTP 4xx-Codes wird der Fehler 404 zurückgegeben. Dies gilt jedoch nicht für die folgenden Codes:
Für 405 wird 501 zurückgegeben.
Für 408 wird 503 zurückgegeben.
HTTP 5xx
Alle HTTP 5xx-Statuscodes werden in der Client-Antwort in HTTP 503 konvertiert.
Eigene Ausnahmeklassen erstellen
Wenn Sie für andere HTTP-Statuscodes andere Ausnahmeklassen erstellen möchten, müssen Sie dazu abgeleitete Klassen von com.google.api.server.spi.ServiceException erstellen. Das folgende Snippet zeigt, wie Sie eine Ausnahmeklasse erstellen, die den Statuscode HTTP 408 repräsentiert:
importcom.google.api.server.spi.ServiceException;// Exceptions must inherit from ServiceExceptionpublicclassRequestTimeoutExceptionextendsServiceException{publicRequestTimeoutException(Stringmessage){super(408,message);}}
Nicht unterstützte HTTP-Statuscodes verwenden
Sie können auch HTTP-Statuscodes verwenden, die nicht in der obigen Liste der unterstützten Codes enthalten sind. Beachten Sie, dass in diesem Fall nicht beabsichtigte Folgen für Clientbibliotheken mit Zugriff auf die API entstehen können. Wenn Sie nicht unterstützte Fehlercodes verwenden möchten, erstellen Sie wie im vorherigen Abschnitt beschrieben eine eigene Ausnahmeklasse und fügen Sie einen neuen Servlet-Initialisierungsparameter enableExceptionCompatibility zu EndpointsServlet hinzu.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eThe \u003ccode\u003eendpoints\u003c/code\u003e library provides exceptions that correspond to common HTTP status codes, allowing developers to indicate the success or failure of API requests.\u003c/p\u003e\n"],["\u003cp\u003eEndpoints Frameworks offers built-in exception classes for HTTP status codes like \u003ccode\u003e400\u003c/code\u003e, \u003ccode\u003e401\u003c/code\u003e, \u003ccode\u003e403\u003c/code\u003e, \u003ccode\u003e404\u003c/code\u003e, \u003ccode\u003e409\u003c/code\u003e, \u003ccode\u003e500\u003c/code\u003e, and \u003ccode\u003e503\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eHTTP \u003ccode\u003e200\u003c/code\u003e and \u003ccode\u003e204\u003c/code\u003e are supported for successful API methods, while HTTP 3xx codes are not supported and will result in an HTTP \u003ccode\u003e404\u003c/code\u003e response.\u003c/p\u003e\n"],["\u003cp\u003eWhile a subset of HTTP 4xx codes are directly supported, many others are converted to \u003ccode\u003e404\u003c/code\u003e, and all HTTP 5xx codes are converted to \u003ccode\u003e503\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers can create custom exception classes for unsupported HTTP status codes by subclassing \u003ccode\u003ecom.google.api.server.spi.ServiceException\u003c/code\u003e and enabling \u003ccode\u003eenableExceptionCompatibility\u003c/code\u003e in the \u003ccode\u003eEndpointsServlet\u003c/code\u003e configuration.\u003c/p\u003e\n"]]],[],null,["# Exceptions and HTTP status codes\n\nThis page lists the exceptions provided by the `endpoints` library as well as\nHTTP status codes supported by Cloud Endpoints Frameworks.\n\nIn many situations, you might want to use common HTTP status codes to indicate\nthe success or failure of a user's API request. For example, if a user is\nattempting to retrieve an entity which doesn't exist, you might want to send an\nHTTP `404` status code to say that no entity exists with ID: `entityId`.\n\nYou can send common HTTP status codes by throwing an exception provided\nby the `endpoints` library as follows: \n\n throw new NotFoundException(user.getEmail());\n\nExceptions provided by Endpoints Frameworks\n-------------------------------------------\n\nEndpoints Frameworks provides the following exceptions, corresponding\nto specific HTTP status codes:\n\nSupported HTTP status codes\n---------------------------\n\nCloud Endpoints Frameworks supports a subset of HTTP status codes\nin API responses. The following table describes the supported codes.\n\n| **Important:** Don't use custom exception classes to return HTTP 2xx codes. Endpoints Frameworks doesn't support returning HTTP `201` or any other 2xx codes except HTTP `200` and HTTP `204` as described in the preceding table.\n\nCreating your own exception classes\n-----------------------------------\n\nIf you want to create other exception classes for other HTTP status codes, you\nneed to subclass `com.google.api.server.spi.ServiceException`. The\nfollowing snippet shows how to create an exception class that represents an\nHTTP `408` status code: \n\n import com.google.api.server.spi.ServiceException;\n\n // Exceptions must inherit from ServiceException\n public class RequestTimeoutException extends ServiceException {\n public RequestTimeoutException(String message) {\n super(408, message);\n }\n }\n\n| **Important:** An uncaught exception in your application results in an HTTP `503` error from your Cloud Endpoints API, unless it extends `com.google.api.server.spi.ServiceException`.\n\nUsing unsupported HTTP status codes\n-----------------------------------\n\nIt is possible to use HTTP status codes that aren't in the preceding supported\nlist. Note that if you decide to do so, it might have unintended consequences\nfor client libraries that access the API. To use unsupported error codes,\ncreate your own exception class, as described in the previous section, and\nadd a new servlet initialization parameter `enableExceptionCompatibility` to\n`EndpointsServlet`: \n\n \u003cservlet\u003e\n \u003cservlet-name\u003ecom.google.api.server.spi.EndpointsServlet\u003c/servlet-name\u003e\n \u003cservlet-class\u003ecom.google.api.server.spi.EndpointsServlet\u003c/servlet-class\u003e\n \u003cinit-param\u003e\n \u003cparam-name\u003eservices\u003c/param-name\u003e\n \u003cparam-value\u003e...\u003c/param-value\u003e\n \u003c/init-param\u003e\n \u003cinit-param\u003e\n \u003cparam-name\u003eenableExceptionCompatibility\u003c/param-name\u003e\n \u003cparam-value\u003etrue\u003c/param-value\u003e\n \u003c/init-param\u003e\n \u003c/servlet\u003e"]]