Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Nesta página, relacionamos as exceções fornecidas pela biblioteca endpoints e os códigos de status HTTP compatíveis com o Cloud Endpoints Frameworks.
Em muitas situações, convém usar códigos de status HTTP comuns para indicar o sucesso ou a falha da solicitação de API de um usuário. Por exemplo, se um usuário está tentando recuperar uma entidade que não existe, convém enviar um código de status HTTP 404 para dizer que não existe nenhuma entidade com o ID: entityId.
É possível enviar códigos de status HTTP comuns lançando uma exceção fornecida pela biblioteca endpoints da maneira a seguir:
thrownewNotFoundException(user.getEmail());
Exceções fornecidas pelo Endpoints Frameworks
O Endpoints Frameworks fornece as seguintes exceções, correspondentes a códigos de status HTTP específicos:
O Cloud Endpoints Frameworks é compatível com um subconjunto de códigos de status HTTP nas respostas da API. A tabela a seguir descreve os códigos compatíveis.
Códigos de status HTTP
Compatibilidade
HTTP 2xx
HTTP 200 é normalmente assumido pelo Endpoints Frameworks se o método da API retornar com sucesso. Se o tipo de resposta do método da API for void ou o valor de retorno do método da API for null, HTTP 204 é definido em vez disso.
HTTP 3xx
Códigos HTTP 3xx não são compatíveis. O uso de qualquer código HTTP 3xx resulta em uma resposta HTTP 404.
HTTP 4xx
Apenas os seguintes códigos HTTP 4xx são compatíveis:
400
401
403
404
409
410
412
413
Quaisquer outros códigos HTTP 4xx são retornados como erro 404, com exceção dos seguintes:
405 é retornado como 501
408 é retornado como 503
HTTP 5xx
Todos os códigos de status HTTP 5xx são convertidos em HTTP 503 na resposta do cliente.
Como criar classes de exceção próprias
Se quiser criar outras classes de exceção para outros códigos de status HTTP, será necessário criar uma subclasse com.google.api.server.spi.ServiceException. O snippet a seguir mostra como criar uma classe de exceção que representa um código de status HTTP 408:
importcom.google.api.server.spi.ServiceException;// Exceptions must inherit from ServiceExceptionpublicclassRequestTimeoutExceptionextendsServiceException{publicRequestTimeoutException(Stringmessage){super(408,message);}}
Como usar códigos de status HTTP não compatíveis
É possível usar códigos de status HTTP que não estejam na lista de compatibilidade acima. Se você decidir fazer isso, poderá haver consequências indesejadas para as bibliotecas de cliente que acessam a API. Para usar códigos de erro não compatíveis, crie sua própria classe de exceção, conforme descrito na seção anterior, e adicione um novo parâmetro de inicialização de servlet enableExceptionCompatibility a EndpointsServlet:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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"]]