Столкнувшись на одном крупном ресурсе для разработчиков с неправильной реализацией REST-архитектуры, я, вслед за компанией Intel, развенчивающей мифы о законе Мура, хочу обратить внимание, на самую частую ошибку при реализации RESTful приложений, нарушающую целостность сети. При чем грешат практически все разработчики, веб-фреймворки и даже очень популярные ресурсы (например GitHub), но...
Начну с небольшой предыстории. Разрабатывая для сайта авторизацию через Oauth, на очередной запрос, мне пришел ответ “404 Not found”. Ничего страшного, подумал я, сверился с документацией, посмотрел в код и удивился – 404-й ошибки быть не должно. Как вы уже догадались, далее я проверил каждую строчку документации и своей программы и потратил некоторое время на поиск ошибки. Когда я ее обнаружил, то был рассержен, и на себя и на разработчиков github. В чем же было дело?
Проблема заключалась в том, что в коде и документации не совпадал HTTP-метод, который был указан в запросе. Постойте! Ведь URL – это идентификатор (точнее его подвид), а значит ни при каких обстоятельствах я не должен был получить 404-ю ошибку (именно эта уверенность меня и подвела). В крайнем случае, я ожидал получить 400-й заголовок “Bad Request”, но уж точно не 404!
Что же должно было произойти на самом деле? В стандарте для этого случая есть HTTP-статус 405 “Method Not Allowed”, в этом случае сервер обязан отправлять с ответом список допустимых методов. Стандарт не уточняет в каком виде должен быть отправлен этот список, но, очевидно, в том виде, в котором клиент сможет его прочесть с учетом заголовка “Accept”.
Как вы уже догадались сегодня тяжело найти веб-фреймворк или ресурс, который бы не повторял эту ошибку, больше свойственную новичкам, нежели суровым профессионалам. По-моему, личному мнению, особенно ярко и, возможно, даже комично это смотрится на фоне развернувшейся во времена популяризации REST-архитектуры борьбы за стандартизацию HTML с высмеиванием Microsoft – HTTP к тому моменту уже был стандартизирован. Результатом этого – возможная потеря обратной совместимости узлов сети, а сегодня к невозможности быстрой интеграции современных продуктов в программные комплексы в виду необходимости индивидуальной настройки каждого такого приложения.
Начну с небольшой предыстории. Разрабатывая для сайта авторизацию через Oauth, на очередной запрос, мне пришел ответ “404 Not found”. Ничего страшного, подумал я, сверился с документацией, посмотрел в код и удивился – 404-й ошибки быть не должно. Как вы уже догадались, далее я проверил каждую строчку документации и своей программы и потратил некоторое время на поиск ошибки. Когда я ее обнаружил, то был рассержен, и на себя и на разработчиков github. В чем же было дело?
Проблема заключалась в том, что в коде и документации не совпадал HTTP-метод, который был указан в запросе. Постойте! Ведь URL – это идентификатор (точнее его подвид), а значит ни при каких обстоятельствах я не должен был получить 404-ю ошибку (именно эта уверенность меня и подвела). В крайнем случае, я ожидал получить 400-й заголовок “Bad Request”, но уж точно не 404!
Что же должно было произойти на самом деле? В стандарте для этого случая есть HTTP-статус 405 “Method Not Allowed”, в этом случае сервер обязан отправлять с ответом список допустимых методов. Стандарт не уточняет в каком виде должен быть отправлен этот список, но, очевидно, в том виде, в котором клиент сможет его прочесть с учетом заголовка “Accept”.
Как вы уже догадались сегодня тяжело найти веб-фреймворк или ресурс, который бы не повторял эту ошибку, больше свойственную новичкам, нежели суровым профессионалам. По-моему, личному мнению, особенно ярко и, возможно, даже комично это смотрится на фоне развернувшейся во времена популяризации REST-архитектуры борьбы за стандартизацию HTML с высмеиванием Microsoft – HTTP к тому моменту уже был стандартизирован. Результатом этого – возможная потеря обратной совместимости узлов сети, а сегодня к невозможности быстрой интеграции современных продуктов в программные комплексы в виду необходимости индивидуальной настройки каждого такого приложения.
