Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se enumeran las excepciones proporcionadas por la biblioteca de endpoints y los códigos de estado HTTP que admite Cloud Endpoints Frameworks.
En muchas situaciones, es posible que desees utilizar códigos de estado HTTP comunes para indicar si la solicitud a la API de un usuario se realizó correctamente o si hubo un error. Por ejemplo, si un usuario intenta recuperar una entidad que no existe, es posible que desees enviar un código de estado HTTP 404 para decir que no existe ninguna entidad con ID: entityId.
Puedes enviar códigos de estado HTTP comunes mediante una excepción provista con la biblioteca de endpoints de la siguiente manera:
thrownewNotFoundException(user.getEmail());
Excepciones proporcionadas por Endpoints Frameworks
Endpoints Frameworks proporciona las siguientes excepciones, correspondientes a códigos de estado HTTP específicos:
Cloud Endpoints Frameworks admite un subconjunto de códigos de estado HTTP en las respuestas de la API. En la siguiente tabla, se describen los códigos compatibles.
Códigos de estado HTTP
Asistencia
HTTP 2xx
HTTP 200 generalmente es el que se supone en Endpoints Frameworks si el método de API es correcto. Si el tipo de respuesta del método API es void o el valor mostrado del método API es null, en su lugar se establece HTTP 204.
HTTP 3xx
Los códigos HTTP 3xx no son compatibles. El uso de cualquier código HTTP 3xx da como resultado una respuesta HTTP 404.
HTTP 4xx
Solo se admiten los siguientes códigos HTTP 4xx:
400
401
403
404
409
410
412
413
Cualquier otro código HTTP 4xx se muestra como error 404, excepto por lo siguiente:
405 se muestra como 501.
408 se muestra como 503.
HTTP 5xx
Todos los códigos de estado HTTP 5xx se convierten en HTTP 503 en la respuesta del cliente.
Crea tus propias clases de excepciones
Si quieres crear clases de excepción diferentes para otros códigos de estado HTTP, debes crear la subclase com.google.api.server.spi.ServiceException. El fragmento siguiente muestra cómo crear una clase de excepción que represente un código de estado HTTP 408:
importcom.google.api.server.spi.ServiceException;// Exceptions must inherit from ServiceExceptionpublicclassRequestTimeoutExceptionextendsServiceException{publicRequestTimeoutException(Stringmessage){super(408,message);}}
Utiliza códigos de estado HTTP no compatibles
Es posible usar códigos de estado HTTP que no se encuentran en la lista compatible anterior. Ten en cuenta que si decides hacerlo, podrías tener consecuencias no deseadas para las bibliotecas cliente que acceden a la API. A fin de usar códigos de error no compatibles, crea tu propia clase de excepción, como se describe en la sección anterior, y agrega un nuevo parámetro de inicialización del servlet enableExceptionCompatibility para EndpointsServlet de la siguiente manera:
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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"]]