405 ошибка rest - Не ошибается лишь тот, кто ничего не делает!

Am asking this question after doing some research. I did followed the solutions given for this kind of error but did not work for me. Any suggestions as where am going wrong in the below code.I am creating a REST API but when I request the url it is giving me the 405 error.Below is the URI am requesting.

    http://localhost:8080/Project/services/start/version

Below is the code snippet.

@Path("/start")

public class StartService {
@GET
@Path("/version")
@Produces({"text/plain","application/xml","application/json"})
public String getVersion() {
    String ver="";

    try{


          Runtime rt = Runtime.getRuntime();
          Process pr = rt.exec("C:\server\dgr -v" );

          BufferedReader stdInput = new BufferedReader(new InputStreamReader
(pr.getInputStream()));
          BufferedReader input = new BufferedReader(stdInput);
         // String ver ="";
          StringBuffer verOutput = new StringBuffer();
                while((ver =  input.readLine()) != null){
                    verOutput.append(ver + "n");
                    System.out.println(ver);
                }


        }catch (Throwable t)  
          {  
            t.printStackTrace();  
          }  


        finally {  

        }
    return ver;  }

}

web.xml:

<web-app 
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">

<servlet>
<display-name>eLicensingWeb</display-name>      
    <servlet-name>JAX-RS REST</servlet-name>
    <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
     <init-param>
         <param-name>com.sun.jersey.config.property.packages</param-name>
        <param-value>com.cem.plc.service</param-value>
    </init-param>

    <load-on-startup>1</load-on-startup>
</servlet>




<servlet-mapping>
    <servlet-name>JAX-RS REST</servlet-name>
    <url-pattern>/services/*</url-pattern>
</servlet-mapping>


<welcome-file-list>
    <welcome-file>index.jsp</welcome-file>
</welcome-file-list>


</web-app>

asked Oct 2, 2013 at 18:20

You might be doing a PUT call for GET operation
Please check once

answered Aug 27, 2020 at 17:59

In above code variable «ver» is assign to null, print «ver» before returning and see the value. As this «ver» having null service is send status as «204 No Content».

And about status code «405 — Method Not Allowed» will get this status code when rest controller or service only supporting GET method but from client side your trying with POST with valid uri request, during such scenario get status as «405 — Method Not Allowed»

answered Jun 27, 2019 at 4:58

GirishGirish

1073 silver badges10 bronze badges

@Produces({"text/plain","application/xml","application/json"})

change this to

@Produces("text/plain")

and try,

shA.t

16.5k5 gold badges54 silver badges111 bronze badges

answered Dec 24, 2013 at 13:13

I also had this problem and was able to solve it by enabling CORS support on the server. In my case it was an Azure server and it was easy: Enable CORS on Azure

So check for your server how it works and enable CORS. I didn’t even need a browser plugin or proxy

answered Jan 21, 2017 at 20:29

seawave_23seawave_23

1,1492 gold badges12 silver badges22 bronze badges

Add

@Produces({"image/jpeg,image/png"})

@POST
@Path("/pdf")
@Consumes({ MediaType.MULTIPART_FORM_DATA })
@Produces({"image/jpeg,image/png"})
//@Produces("text/plain")
public Response uploadPdfFile(@FormDataParam("file") InputStream fileInputStream,@FormDataParam("file") FormDataContentDisposition fileMetaData) throws Exception {
    ...
}

bluish

26k27 gold badges120 silver badges179 bronze badges

answered Sep 1, 2016 at 15:48

GeneGene

10.8k1 gold badge66 silver badges58 bronze badges

I had the same issue. In my case the Url had portions of it missing
For example :

http://localhost:8080/root/path/action

Instead I had something like

http://localhost:8080/root/action

Take away is check if the URL is correct. In my case I corrected my URL and the issue was resolved.

answered Jun 2, 2022 at 6:47

GayathriGayathri

651 silver badge11 bronze badges

When I got 405 when making a rest call, I did all research and none worked for me. Finally I realized I did not put the right version of code in tomcat. Once the code with the method is in place, the rest call worked. Just want to put here FYI.
Please check your version of code first!!!!

answered May 26, 2022 at 18:49

JanetJanet

7429 silver badges13 bronze badges

Источник

REST API использует строку состояния в HTTP ответе (статус ответа), чтобы информировать Клиентов о результате запроса.

Вообще HTTP определяет 40 стандартных кодов состояния (статусов ответа), которые делятся на пять категорий. Ниже выделены только те коды состояния, которые часто используются в REST API.

Категория	Описание
1xx: Информация	В этот класс содержит заголовки информирующие о процессе передачи. Это обычно предварительный ответ, состоящий только из Status-Line и опциональных заголовков, и завершается пустой строкой. Нет обязательных заголовков. Серверы НЕ ДОЛЖНЫ посылать 1xx ответы HTTP/1.0 клиентам.
2xx: Успех	Этот класс кодов состояния указывает, что запрос клиента был успешно получен, понят, и принят.
3xx: Перенаправление	Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям.
4xx: Ошибка клиента	Класс кодов 4xx предназначен для указания ошибок со стороны клиента.
5xx: Ошибка сервера	Коды ответов, начинающиеся с «5» указывают на случаи, когда сервер знает, что произошла ошибка или он не может обработать запрос.

Коды состояний в REST

Звездочкой * помечены популярные (часто используемые) коды ответов.

200 * (OK)

Запрос выполнен успешно. Информация, возвращаемая с ответом зависит от метода, используемого в запросе, например при:

GET Получен объект, соответствующий запрошенному ресурсу.
HEAD Получены поля заголовков, соответствующие запрошенному ресурсу, тело ответа пустое.
POST Запрошенное действие выполнено.

201 * (Created — Создано)

REST API отвечает кодом состояния 201 при каждом создании ресурса в коллекции. Также могут быть случаи, когда новый ресурс создается в результате какого-либо действия контроллера, и в этом случае 201 также будет подходящем ответом.

Ссылка (URL) на новый ресурс может быть в теле ответа или в поле заголовка ответа Location.

Сервер должен создать ресурс перед тем как вернуть 201 статус. Если это невозможно сделать сразу, тогда сервер должен ответить кодом 202 (Accepted).

202 (Accepted — Принято)

Ответ 202 обычно используется для действий, которые занимают много времени для обработки и не могут быть выполнены сразу. Это означает, что запрос принят к обработке, но обработка не завершена.

Его цель состоит в том, чтобы позволить серверу принять запрос на какой-либо другой процесс (возможно, пакетный процесс, который выполняется только один раз в день), не требуя, чтобы соединение агента пользователя с сервером сохранялось до тех пор, пока процесс не будет завершен.

Сущность, возвращаемая с этим ответом, должна содержать указание на текущее состояние запроса и указатель на монитор состояния (расположение очереди заданий) или некоторую оценку того, когда пользователь может ожидать выполнения запроса.

203 (Non-Authoritative Information — Неавторитетная информация)

Предоставленная информация взята не из оригинального источника (а, например, из кэша, который мог устареть, или из резервной копии, которая могла потерять актуальность). Этот факт отражен в заголовке ответа и подтверждается этим кодом. Предоставленная информация может совпадать, а может и не совпадать с оригинальными данными.

204 * (No Content — Нет контента)

Код состояния 204 обычно отправляется в ответ на запрос PUT, POST или DELETE, когда REST API отказывается отправлять обратно любое сообщение о состоянии проделанной работы.

API может также отправить 204 статус в ответ на GET запрос, чтобы указать, что запрошенный ресурс существует, но не имеет данных для добавления их в тело ответа.

Ответ 204 не должен содержать тело сообщения и, таким образом, всегда завершается первой пустой строкой после полей заголовка.

205 — (Reset Content — Сброшенное содержимое)

Сервер успешно обработал запрос и обязывает клиента сбросить введенные пользователем данные. В ответе не должно передаваться никаких данных (в теле ответа). Обычно применяется для возврата в начальное состояние формы ввода данных на клиенте.

206 — (Partial Content — Частичное содержимое)

Сервер выполнил часть GET запроса ресурса. Запрос ДОЛЖЕН был содержать поле заголовка Range (секция 14.35), который указывает на желаемый диапазон и МОГ содержать поле заголовка If-Range (секция 14.27), который делает запрос условным.

Запрос ДОЛЖЕН содержать следующие поля заголовка:

Либо поле Content-Range (секция 14.16), который показывает диапазон, включённый в этот запрос, либо Content-Type со значением multipart/byteranges, включающими в себя поля Content-Range для каждой части. Если в заголовке запроса есть поле Content-Length, его значение ДОЛЖНО совпадать с фактическим количеством октетов, переданных в теле сообщения.
Date
ETag и/или Content-Location, если ранее был получен ответ 200 на такой же запрос.
Expires, Cache-Control, и/или Vary, если значение поля изменилось с момента отправления последнего такого же запроса

Если ответ 206 — это результат выполнения условного запроса, который использовал строгий кэш-валидатор (подробнее в секции 13.3.3), в ответ НЕ СЛЕДУЕТ включать какие-либо другие заголовки сущности. Если такой ответ — результат выполнения запроса If-Range, который использовал «слабый» валидатор, то ответ НЕ ДОЛЖЕН содержать другие заголовки сущности; это предотвращает несоответствие между закэшированными телами сущностей и обновлёнными заголовками. В противном случае ответ ДОЛЖЕН содержать все заголовки сущностей, которые вернули статус 200 (OK) на тот же запрос.

Кэш НЕ ДОЛЖЕН объединять ответ 206 с другими ранее закэшированными данными, если поле ETag или Last-Modified в точности не совпадают (подробнее в секции 16.5.4)

Кэш, который не поддерживает заголовки Range и Content-Range НЕ ДОЛЖЕН кэшировать ответы 206 (Partial).

300 — (Multiple Choices — Несколько вариантов)

По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю.

Если это не запрос HEAD, ответ ДОЛЖЕН включать объект, содержащий список характеристик и адресов, из которого пользователь или агент пользователя может выбрать один наиболее подходящий. Формат объекта определяется по типу данных приведённых в Content-Type поля заголовка. В зависимости от формата и возможностей агента пользователя, выбор наиболее подходящего варианта может выполняться автоматически. Однако эта спецификация не определяет никакого стандарта для автоматического выбора.

Если у сервера есть предпочтительный выбор представления, он ДОЛЖЕН включить конкретный URI для этого представления в поле Location; агент пользователя МОЖЕТ использовать заголовок Location для автоматического перенаправления к предложенному ресурсу. Этот запрос может быть закэширован, если явно не было указано иного.

301 (Moved Permanently — Перемещено навсегда)

Код перенаправления. Указывает, что модель ресурсов REST API была сильно изменена и теперь имеет новый URL. Rest API должен указать новый URI в заголовке ответа Location, и все будущие запросы должны быть направлены на указанный URI.

Вы вряд ли будете использовать этот код ответа в своем API, так как вы всегда можете использовать версию API для нового API, сохраняя при этом старый.

302 (Found — Найдено)

Является распространенным способом выполнить перенаправление на другой URL. HTTP-ответ с этим кодом должен дополнительно предоставит URL-адрес куда перенаправлять в поле заголовка Location. Агенту пользователя (например, браузеру) предлагается в ответе с этим кодом сделать второй запрос на новый URL.

Многие браузеры реализовали этот код таким образом, что нарушили стандарт. Они начали изменять Тип исходного запроса, например с POST на GET. Коды состояния 303 и 307 были добавлены для серверов, которые хотят однозначно определить, какая реакция ожидается от клиента.

303 (See Other — Смотрите другое)

Ответ 303 указывает, что ресурс контроллера завершил свою работу, но вместо отправки нежелательного тела ответа он отправляет клиенту URI ресурса. Это может быть URI временного сообщения о состоянии ресурса или URI для уже существующего постоянного ресурса.

Код состояния 303 позволяет REST API указать ссылку на ресурс, не заставляя клиента загружать ответ. Вместо этого клиент может отправить GET запрос на URL указанный в заголовке Location.

Ответ 303 не должен кэшироваться, но ответ на второй (перенаправленный) запрос может быть кэшируемым.

304 * (Not Modified — Не изменен)

Этот код состояния похож на 204 (Нет контента), так как тело ответа должно быть пустым. Ключевое различие состоит в том, что 204 используется, когда нет ничего для отправки в теле, тогда как 304 используется, когда ресурс не был изменен с версии, указанной заголовками запроса If-Modified-Since или If-None-Match.

В таком случае нет необходимости повторно передавать ресурс, так как у клиента все еще есть ранее загруженная копия.

Все это экономит ресурсы клиента и сервера, так как только заголовки должны быть отправлены и приняты, и серверу нет необходимости генерировать контент снова, а клиенту его получать.

305 — (Use Proxy — Используйте прокси)

Доступ к запрошенному ресурсу ДОЛЖЕН быть осуществлен через прокси-сервер, указанный в поле Location. Поле Location предоставляет URI прокси. Ожидается, что получатель повторит этот запрос с помощью прокси. Ответ 305 может генерироваться ТОЛЬКО серверами-источниками.

Заметьте: в спецификации RFC 2068 однозначно не сказано, что ответ 305 предназначен для перенаправления единственного запроса, и что он должен генерироваться только сервером-источником. Упущение этих ограничений вызвало ряд значительных последствий для безопасности.

Многие HTTP клиенты (такие, как Mozilla и Internet Explorer) обрабатывают этот статус некорректно прежде всего из соображений безопасности.

307 (Temporary Redirect — Временный редирект)

Ответ 307 указывает, что rest API не будет обрабатывать запрос клиента. Вместо этого клиент должен повторно отправить запрос на URL, указанный в заголовке Location. Однако в будущих запросах клиент по-прежнему должен использоваться исходный URL.

Rest API может использовать этот код состояния для назначения временного URL запрашиваемому ресурсу.

Если метод запроса не HEAD, тело ответа должно содержать короткую заметку с гиперссылкой на новый URL. Если код 307 был получен в ответ на запрос, отличный от GET или HEAD, Клиент не должен автоматически перенаправлять запрос, если он не может быть подтвержден Клиентом, так как это может изменить условия, при которых был создан запрос.

308 — (Permanent Redirect — Постоянное перенаправление) (experimental)

Нужно повторить запрос на другой адрес без изменения применяемого метода.

Этот и все последующие запросы нужно повторить на другой URI. 307 и 308 (как предложено) Схож в поведении с 302 и 301, но не требуют замены HTTP метода. Таким образом, например, отправку формы на «постоянно перенаправленный» ресурс можно продолжать без проблем.

400 * (Bad Request — Плохой запрос)

Это общий статус ошибки на стороне Клиента. Используется, когда никакой другой код ошибки 4xx не уместен. Ошибки могут быть как неправильный синтаксис запроса, неверные параметры запроса, запросы вводящие в заблуждение или маршрутизатор и т.д.

Клиент не должен повторять точно такой же запрос.

401 * (Unauthorized — Неавторизован)

401 сообщение об ошибке указывает, что клиент пытается работать с закрытым ресурсом без предоставления данных авторизации. Возможно, он предоставил неправильные учетные данные или вообще ничего. Ответ должен включать поле заголовка WWW-Authenticate, содержащего описание проблемы.

Клиент может повторить запрос указав в заголовке подходящее поле авторизации. Если это уже было сделано, то в ответе 401 будет указано, что авторизация для указанных учетных данных не работает. Если в ответе 401 содержится та же проблема, что и в предыдущем ответе, и Клиент уже предпринял хотя бы одну попытку проверки подлинности, то пользователю Клиента следует представить данные полученные в ответе, владельцу сайта, так как они могут помочь в диагностике проблемы.

402 — (Payment Required — Требуется оплата)

Этот код зарезервирован для использования в будущем.

Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

403 * (Forbidden — Запрещено)

Ошибка 403 указывает, что rest API отказывается выполнять запрос клиента, т.е. Клиент не имеет необходимых разрешений для доступа. Ответ 403 не является случаем, когда нужна авторизация (для ошибки авторизации используется код 401).

Попытка аутентификация не поможет, и повторные запросы не имеют смысла.

404 * (Not Found — Не найдено)

Указывает, что rest API не может сопоставить URL клиента с ресурсом, но этот URL может быть доступен в будущем. Последующие запросы клиента допустимы.

404 не указывает, является ли состояние временным или постоянным. Для указания постоянного состояния используется код 410 (Gone — Пропал). 410 использоваться, если сервер знает, что старый ресурс постоянно недоступен и более не имеет адреса.

405 (Method Not Allowed — Метод не разрешен)

API выдает ошибку 405, когда клиент пытался использовать HTTP метод, который недопустим для ресурса. Например, указан метод PUT, но такого метода у ресурса нет.

Ответ 405 должен включать Заголовок Allow, в котором перечислены поддерживаемые HTTP методы, например, Allow: GET, POST.

406 (Not Acceptable — Неприемлемый)

API не может генерировать предпочитаемые клиентом типы данных, которые указаны в заголовке запроса Accept. Например, запрос клиента на данные в формате application/xml получит ответ 406, если API умеет отдавать данные только в формате application/json.

В таких случаях Клиент должен решить проблему данных у себя и только потом отправлять запросы повторно.

407 — (Proxy Authentication Required — Требуется прокси-аутентификация)

Ответ аналогичен коду 401, за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере.

Пользователь должен сначала авторизоваться через прокси. Прокси-сервер должен вернуть Proxy-Authenticate заголовок, содержащий запрос ресурса. Клиент может повторить запрос вместе с Proxy-Authenticate заголовком. Появился в HTTP/1.1.

408 — (Request Timeout — Таймаут запроса)

Время ожидания сервером передачи от клиента истекло. Клиент не предоставил запрос за то время, пока сервер был готов его принят. Клиент МОЖЕТ повторить запрос без изменений в любое время.

Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос.

409 * (Conflict — Конфликт)

Запрос нельзя обработать из-за конфликта в текущем состоянии ресурса. Этот код разрешается использовать только в тех случаях, когда ожидается, что пользователь может самостоятельно разрешить этот конфликт и повторить запрос. В тело ответа СЛЕДУЕТ включить достаточное количество информации для того, чтобы пользователь смог понять причину конфликта. В идеале ответ должен содержать такую информацию, которая поможет пользователю или его агенту исправить проблему. Однако это не всегда возможно и это не обязательно.

Как правило, конфликты происходят во время PUT-запроса. Например, во время использования версионирования, если сущность, к которой обращаются методом PUT, содержит изменения, конфликтующие с теми, что были сделаны ранее третьей стороной, серверу следует использовать ответ 409, чтобы дать понять пользователю, что этот запрос нельзя завершить. В этом случае в ответной сущности должен содержаться список изменений между двумя версиями в формате, который указан в поле заголовка Content-Type.

410 — (Gone — Исчез)

Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии. Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.

411 — (Length Required — Требуется длина)

Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение.

412 — (Precondition Failed — Предварительное условие не выполнено)

Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.

Когда клиент указывает rest API выполнять запрос только при выполнении определенных условий, а API не может выполнить запрос при таких условиях, то возвращается ответ 412.

Этот код ответа позволяет клиенту записывать предварительные условия в метаинформации текущего ресурса, таким образом, предотвращая применение запрошенного метода к ресурсу, кроме того, что ожидается.

413 — (Request Entity Too Large — Сущность запроса слишком большая)

Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса.

Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос.

414 — (Request-URI Too Long — Запрос-URI Слишком длинный)

Сервер не может обработать запрос из-за слишком длинного указанного URL. Эту редкую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST, когда клиент попадает в «чёрную дыру» перенаправлений (например, когда префикс URI указывает на своё же окончание), или когда сервер подвергается атаке со стороны клиента, который пытается использовать дыры в безопасности, которые встречаются на серверах с фиксированной длиной буфера для чтения или обработки Request-URI.

415 (Unsupported Media Type — Неподдерживаемый медиа тип)

Сообщение об ошибке 415 указывает, что API не может обработать предоставленный клиентом Тип медиа, как указано в заголовке запроса Content-Type.

Например, запрос клиента содержит данные в формате application/xml, а API готов обработать только application/json. В этом случае клиент получит ответ 415.

Например, клиент загружает изображение как image/svg+xml, но сервер требует, чтобы изображения использовали другой формат.

428 — (Precondition Required — Требуется предварительное условие)

Код состояния 428 указывает, что исходный сервер требует, чтобы запрос был условным.

Его типичное использование — избежать проблемы «потерянного обновления», когда клиент ПОЛУЧАЕТ состояние ресурса, изменяет его и ОТПРАВЛЯЕТ обратно на сервер, когда тем временем третья сторона изменила состояние на сервере, что привело к конфликту. Требуя, чтобы запросы были условными, сервер может гарантировать, что клиенты работают с правильными копиями.

Ответы с этим кодом состояния ДОЛЖНЫ объяснять, как повторно отправить запрос.

429 — (Too Many Requests — Слишком много запросов)

Пользователь отправил слишком много запросов за заданный промежуток времени.

Представления ответа ДОЛЖНЫ включать подробности, объясняющие условие, и МОГУТ включать заголовок Retry-After, указывающий, как долго ждать, прежде чем делать новый запрос.

431 — (Request Header Fields Too Large — Слишком большие поля заголовка запроса)

Код состояния 431 указывает на то, что сервер не желает обрабатывать запрос, поскольку его поля заголовка слишком велики. Запрос МОЖЕТ быть отправлен повторно после уменьшения размера полей заголовка запроса.

Его можно использовать как в случае, когда совокупность полей заголовка запроса слишком велика, так и в случае неисправности одного поля заголовка. В последнем случае представление ответа ДОЛЖНО указывать, какое поле заголовка было слишком большим.

444 — (No Response — Нет ответа) (Nginx)

Код ответа Nginx. Сервер не вернул информацию и закрыл соединение. (полезно в качестве сдерживающего фактора для вредоносных программ)

451 — (Unavailable For Legal Reasons — Недоступен по юридическим причинам)

Доступ к ресурсу закрыт по юридическим причинам. Наиболее близким из существующих является код 403 Forbidden (сервер понял запрос, но отказывается его обработать). Однако в случае цензуры, особенно когда это требование к провайдерам заблокировать доступ к сайту, сервер никак не мог понять запроса — он его даже не получил. Совершенно точно подходит другой код: 305 Use Proxy. Однако такое использование этого кода может не понравиться цензорам. Было предложено несколько вариантов для нового кода, включая «112 Emergency. Censorship in action» и «460 Blocked by Repressive Regime»

500 * (Internal Server Error — Внутренняя ошибка сервера)

Общий ответ при ошибке в коде. Универсальное сообщение о внутренней ошибке сервера, когда никакое более определенное сообщение не подходит.

Большинство веб-платформ автоматически отвечают этим кодом состояния, когда при выполнении кода обработчика запроса возникла ошибка.

Ошибка 500 никогда не зависит от клиента, поэтому для клиента разумно повторить точно такой же запрос, и надеяться что в этот раз сервер отработает без ошибок.

501 (Not Implemented — Не реализован)

Серверу либо неизвестен метод запроса, или ему (серверу) не хватает возможностей выполнить запрос. Обычно это подразумевает будущую доступность (например, новая функция API веб-сервиса).

Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405.

502 — (Bad Gateway — Плохой шлюз)

Сервер, выступая в роли шлюза или прокси-сервера, получил некорректный ответ от вышестоящего сервера, к которому он обратился. Появился в HTTP/1.0.

503 — (Service Unavailable — Служба недоступна)

Сервер не может обработать запрос из-за временной перегрузки или технических работ. Это временное состояние, из которого сервер выйдет через какое-то время. Если это время известно, то его МОЖНО передать в заголовке Retry-After.

504 — (Gateway Timeout — Таймаут шлюза)

Сервер, в роли шлюза или прокси-сервера, не дождался в рамках установленного таймаута ответа от вышестоящего сервера текущего запроса.

505 — (HTTP Version Not Supported — Версия HTTP не поддерживается)

Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.

510 — (Not Extended — Не расширен)

В запросе не соблюдена политика доступа к ресурсу. Сервер должен отправить обратно всю информацию, необходимую клиенту для отправки расширенного запроса. Указание того, как расширения информируют клиента, выходит за рамки данной спецификации.

—

Источники и более подробная информация:

https://restapitutorial.ru/httpstatuscodes.html
https://www.restapitutorial.com/httpstatuscodes.html
https://restfulapi.net/http-status-codes/
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/428

Источник

Photo by Joanna Kosinska on Unsplash

For more than 10 years we’ve been working with HTTP and APIs following the ReST architecture. Most people think that APIs are just interfaces you can use to interact with some third-party program and that ReST is all about HTTP verbs, however, most of the communication we use nowadays may be wrong just because we are using wrong HTTP status codes to express our responses. And this can be a life changer when we’re talking of modern web applications.

That’s right! An API is much more expressive than just writing GET to fetch data or POST to create data, this is the request part, what about the response?

In this article, we’ll explore a bit more about HTTP Status Codes, when to use each one of them and their definitions! So, let’s dive in!

Summary

Summary
What are HTTP Status Codes?
Code Classes
Why do I need to know them?
Picking the right code for your API
- Most Used API Codes
- 200x
  - 200 — OK
  - 201 — Created
- 300x
  - 301 — Moved Permanently
  - 302 — Found
- 400x
  - 400 — Bad Request
  - 401 — Unauthorized
  - 403 — Forbidden
  - 404 — Not Found
  - 405 — Method not allowed
  - 429 — Too many requests
- 500x
  - 500 — Internal Server Error
  - 502 — Bad Gateway
  - 503 — Service Unavailable
  - 504 — Gateway Timeout
Coffee Break

What are HTTP Status Codes?

Every protocol we use today has been defined and specified in a document we call Request For Comments, or simply, RFC, HTTP Status Codes are defined along with the HTTP protocol itself within the RFC2616, the document that defines what is HTTP/1.1, more specifically, on section 10. They’re also defined on the RFC7231 section 6 about HTTP/1.1 Semantics. They’re a number code that varies from 100 to 500ish and aims to make the HTTP response more meaningful to the client.

Incredible, we’ve cited the whole history of the Internet just to get a definition, right? But what does it mean? Every time we click on a button and send a request to a client-server-based application, this application answers us with another HTTP-based response, both the request and the response contains a header, which is responsible for giving us the context of that requisition. Status codes come on every response in a header called Status (how original), and they are there just to give us a clue of what happened to our request after it’s been processed.

Most of the time, common users won’t see those status codes – unless something went terribly wrong – but, for us, programmers, they’re extremely valuable. For instance, every time we cannot find a resource or a webpage we’re presented with a 404 error page, this 404 is the HTTP status code for Not Found.

In short, they give us more information about what’s happening and what has happened to the request we made, and they’re pretty valuable to front-enders who want to show the correct status messages based on what the server has answered.

Code Classes

As we mentioned earlier, HTTP Status Codes are numbered from 100 to 500, however, this interval is not entirely filled, for example, we do not have a 174 status code because this was made to split codes into categories. These categories are defined in hundreds, each hundred of the HTTP interval represents a different category or class:

100s: These are informational codes, just to acknowledge that the request has been received and it’s being processed.
200s: Success codes, returned when everything has been processed or understood properly, generally, this means that the client does not need to perform any more actions
300s: Redirection codes, meaning that the client should request that resource somewhere else
400s: Client error codes, when the client messed things up
500s: Server error codes, when the server messed things up

Why do I need to know them?

Status codes are not only important to programmers because we need to know what’s happening so we can perform validations or error messaging, but also they’re important to monitor the health of our application, as well as SEO.

In monitoring, is easier to know the health of an application by its status code, for example, if your website is returning a lot of 404s, probably someone messed up and forgot to put some page online, however, if your application is displaying a lot of 500s, it is probably offline and no one can use it. So it is a lot easier for the dev team to debug an application when it displays the correct information.

On the other hand, out of the dev environment, when we talk about SEO, status codes are the only way the crawling bots can understand what is happening when they «see» your website. This means that, if you’re a blind robot that only understands status codes then if a page keeps returning 404, this means that this page is not very good since it does not exist, so its rank should be lower than other pages that return a 200 status code because they DO exist.

I won’t explain this in much detail here because our focus is on the status codes and their returns, but you can read more about it in this excellent article I used for reference.

Picking the right code for your API

In this section, we’ll go through all the defined status codes and their meanings, but we’ll do it differently. Let’s split this section into three:

Most used API codes, where we’ll talk about the codes we already use and how should we use them properly
Codes not-so-often used, but we should use it more
Other codes, where we’ll finish the guide explaining less used status codes, which doesn’t mean they’re useless – except for one

In this article, we’ll cover just the first part so it is not a very loooong reading for all of you! But, in the next articles of the series, we’ll be covering the other two parts!

And we’ll illustrate everything with cats and dogs so we can have a little fun while doing it!

Most Used API Codes

First of all, let’s dive in the most common stuff, there won’t be much new content here, after all, they’re already mostly used. So let’s go through the most common of the status codes by classes:

200x

200 — OK

I believe this is the most common status code ever returned

The 200 OK is the standard response for successful requests. Generally, this is what we are eager to see. However, the response for this code should differ from an HTTP Method to another as described in the RFC7231.

When to use it: Generally there’s another HTTP Status Code that would express what you want to say in a better way, but, if you have doubts about what HTTP code to use and your response is a success, then 200 it is!

201 — Created

This status code is usually used along with the POST method since it describes a resource that has been created into the server after the successful fulfillment of the request.

Take a look at the definition

When to use it: When creating stuff. For example, when you create a new user in the database, the response should be 201 with the newly created document as the body.

300x

301 — Moved Permanently

Used when the resource you’re looking for has been permanently moved to another location. This status code usually comes along with another header telling the exact location where the resource has been moved.

When to use it: Normally used for permanent redirections, for instance, a website that has an index page on http://contoso.com and should be redirected to http://foo.com. But the catch is, this status code should only be used with GET or HEAD request methods, for all other methods we should use 308

302 — Found

Despite the text «found» don’t give us much clue of what this is all about, the 302 status code is commonly used by temporary redirects, telling that the resource has been moved but it has been found on another URI described in the Location header.

When to use it: Mostly the same thing as 301, but used on temporary redirections where the resource will eventually be found in the current URL again. However, the rule applies, this status code should only be used with GET or HEAD request methods, for all other methods we should use 307

400x

400 — Bad Request

This status code is the official representation of the phrase «don’t know, don’t care». Since it only says that the server has found an error in the client’s request and was unable to process it. The biggest mistake of most web developers is to return this error for EVERY request that they cannot handle. Which reduces the amount of information given to the client and, therefore, the meaningfulness of the API.

When to use it: When you have tried everything and still could not find what was wrong with the request. Otherwise, please use a more meaningful error code.

401 — Unauthorized

The 401 status code is normally mistaken with 403, the biggest difference is that, in the case of 401, the client is still not authenticated, therefore it cannot access the page

When to use it: When a resource cannot be accessed due to authentication reasons, normally used in login pages when the user tries to log in with a wrong user/password

403 — Forbidden

Differently from 401, the 403 status code refers to a resource that is off the limits for the request for any other reason other than authorization, for example, scope limiting.

When to use it: Generally used when we have a boundary to what users can do in the application, for instance, if I’m not the admin I should not be allowed to delete other users, therefore, if I try to do so, I’ll get a 403 — Forbidden error. The rule of thumb is to remember the following sequence:

If I don’t know who is making the request, then it’s 401 — Unauthorized
If I do know who’s making the request, but the user doesn’t have permissions to do so, then it’s 403 — Forbidden

404 — Not Found

The 404 status code is the most familiar to everyone, even those who are not devs. It is pretty straight forward, the resource you were looking for could not be found on this site.

When to use it: When you cannot find a page or resource, a not-so-known use case is to return 404 when a find query – like /users/1234 – returns null. This is a good practice because the user was looking for a specific resource and it does not exist. On the other hand, if you’re on a search query – like /users – where you could return 0 or more then the default response for «There are no users registered» or «Empty list» would be 200.

405 — Method not allowed

Generally, when we don’t implement a route but it is there, we use the 405 status code. This code says that the method we’re using is a known method to the server – which means it can process it – however that particular resource does not accept it.

When to use it: Let’s explain by example. If you have a POST /users and a GET /users but do not have a DELETE /users, then if I try to DELETE /users you should return a 405 status code to me, this status code generally comes along with another header called Allow stating which methods are allowed.

429 — Too many requests

The classic «Are you trying to DDoS me?». The 429 status code is defined on another RFC, the RFC-6585 for additional HTTP headers. It states that the requester has sent too many requests in a given amount of time, this is what we call rate limiting.

When to use it: This should be the default to all APIs out there that don’t want to be crashed by DDoS attacks, but, since this is not the case today, the most common use case to this status code is to limit the number of requests that a user can make before it is blocked by the server. Most API gateways and user-exposed APIs use it, like Twitter, for instance, which allows about 15 requests per minute.

Also, if you’re looking to do it yourself, Azure has a pretty cool tool that makes it possible

500x

500 — Internal Server Error

The classic «I messed things up». This status code is sent as the response when the server did something wrong on its side and do not know how to proceed. If a user is seeing this, then your application is in bad shape, since these status codes should be visible only to the internal side of the application. The user side should format the error and show a more user-friendly message.

When to use it: When an exception is thrown by the server and not caught and you do not know what happened, but you do know it is on the server. I’ve seen a lot of people using 400 status codes to show server-side errors, this is wrong on so many levels…

502 — Bad Gateway

This status code is meant for proxied servers. It states that the server which is acting as a gateway or a proxy could not complete the request, or it received an invalid one from the client.

When to use it: The programmer should never need to use it manually unless you’re writing a proxy API or a proxy server, in this case, you need to return this message instead of the 500 error we mentioned earlier.

503 — Service Unavailable

The 503 code is more of an information code than an error one since it states that the server handling the requests is not available due to an overload or scheduled maintenance. In the case of the latter, the server can optionally send a Retry-After header with an amount of time so the user can try again.

When to use it: As I mentioned on the other 500x errors, this code is usually not set by programmers since it is on server-side code, unless you’re the developer of a server, in this case, the use case is pretty obvious.

504 — Gateway Timeout

This code is a variation from the 502 code, the difference is that instead of not receiving a good request, the upstream server did not send the request within the expected time frame.

When to use it: This code should be only returned if you’re coding a gateway and the proxied server did not answer your request.

Coffee Break!

Stop for now! Grab a coffee as you prepare for the next part of this series, where we’ll talk about the APIs we don’t see very often, but we should.

See ya!

Источник