Ошибка REST API стала головной болью для большинства владельцев сайтов на WordPress с того момента, как в панели управления (панели администратора) появился раздел «Здоровье сайта». Тревожное сообщение — «Запрос к REST API неудачен из-за ошибки» — не поддавалось разгадке без специальных знаний в области разработки на PHP. Учитывая, что среди пользователей WordPress программистов чуть больше одной десятой процента, проблема стала актуальной для миллионов менее чем за год.
Решение я нашёл самостоятельно и, без сложных объяснений, сразу перейду к нему.
Ошибка в теме сайта
Способ может показаться слишком простым, но достаточно переключиться на одну из новых стандартных тем WordPress, как сообщение об ошибке REST API исчезает. Возвращаемся к старому дизайну — ошибка возвращается.
Точно также происходит и с другой распространённой проблемой, которая называется «ваш сайт не смог выполнить петлевой запрос». Если в разделе «Здоровье сайта» система сообщает, что «петлевой запрос к вашему сайту не удался. Возможности, зависящие от его работоспособности, не могут работать так, как должны» — знайте, что пришло время менять тему вашего сайта.
Что делать
Самое действенное решение — установить более современный темплейт. Быстро и радикально, но не всегда подходит. Особенно, если сайту десяток лет, он выстрадан, сбалансирован и его любят посетители. Для таких проектов резкие движения противопоказаны. В этом случае, выбираем более трудоёмкий путь.
Вам нужен прилежный верстальщик, а лучше в паре с талантливым дизайнером, а ещё лучше чтобы с ними рядом трудился над вашим проектом разработчик на PHP. Пара недель (или месяцев) страданий, пара сотен (или тысяч) долларов — и ваш сайт снова молод, свеж и пахуч.
Примечание: сайт, который вы сейчас видите, читая этот текст, работает в паре со стандартной темой «Twenty Fifteen». В данный момент, версия темы — 2.5, но ни сейчас, ни на одной из прежних версий «Fifteen» я ни разу не получал уведомлений об ошибках REST API или петлевых запросов.
Для тех, кто владеет английским языком — документ в формате Portable Document Format (PDF), с полным описанием архитектурного стиля разработки REST и его стандартов.
В связи с появлением свободного времени, решил Я проверить техническое состояние своего сайта, произвести обновление различных компонентов (WordPress, PHP, MySQl, Apache и т.д) и проверить работоспособность программного обеспечения. Открыв «Здоровье сайта» если кто не знает это встроенный инструмент для диагностики состояния системы и сервера, я увидел сообщение о двух критических проблемах «Обнаружена активная PHP сессия» и «REST API выдал ошибку». Когда появились эти ошибки было не понятно, но думаю достаточно давно так как данный инструмент последний раз Я открывал наверно еще в прошлом году. Влияние этих ошибок на работоспособность сайта было совсем не значительное, так как сайт работал в штатном режиме. Но раз проблемы есть да и еще критические их хотелось решить. Поискав информацию в интернете, Я понял что в большинстве случаем причины появления этих ошибка практически одинаковые, и решение одно и тоже. Сегодня хочу поделиться своим случаем.
WordPress как убрать критические проблемы
И так вы обнаружили следующие критические проблемы на своем сайте.
Обнаружена активная PHP сессия
Сессия PHP была создана вызовом функции
session_start(). Это препятствует работе REST API и петлевых запросов. Сессия должна быть закрыта функциейsession_write_close()перед выполнением любых HTTP-запросов.
REST API выдал ошибку
REST API — один из способов коммуникации WordPress и других приложений с сервером. К примеру, экран редактора блоков использует его для отображения и сохранения ваших записей и страниц.
Запрос к REST API неудачен из-за ошибки.
Ошибка: cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received (http_requ
В 99% случаев эти ошибки связаны с установленными плагинами и темами. Что нужно сделать, для начала произвести обновление, если это не поможет то по очереди отключать плагины и проверять состояние, если и это не поможет то нужно переустановить тему. Если тема доработана и переустановка приведет к потери всех изменений то можно просто поменять на стандартную.
В моем случае причиной появления ошибок «Обнаружена активная PHP сессия» и «REST API выдал ошибку» стал плагин «Капча».
После его отключения все критические проблемы пропали.
Плагины могут быть причиной и других ошибок и даже замедлять работу сайта. В общем если возникают какие либо проблемы с работоспособностью сайта в первую очередь нужно проверить плагины и установленную тему, это касается в первую очередь WordPress.
If your WordPress site is returning an error message such as “Updating Failed” or “Publishing Failed” when you try to make changes, the results can be not only frustrating but can also prevent visitors from accessing what they need.
Fortunately, there are a few common causes and workarounds that can help you resolve this issue if you encounter it. With a little troubleshooting, you should be back to your regular posting schedule in no time.
In this article, we’ll discuss what causes the “Updating Failed” and “Publishing Failed” errors in WordPress. Then we’ll explain four ways you can fix or work around the problem, to get your content up for readers.
Let’s get to it!
Why WordPress Sometimes Fails to Update or Publish Content
The Block Editor has been around for a while now. It’s still being met with mixed reactions, however, and there are also new challenges and errors that WordPress users can face because of it.
One such issue is a message reading “Publishing Failed” in the WordPress editor:
This message may appear after you click on the blue Publish button, in an attempt to make your content live. A variation of this error is the “Updating Failed” message, which may show up when you attempt to make changes to a post or page that you’ve already published:
As you can imagine, this problem can be an especially frustrating one for bloggers, as well as any site owner who finds themselves needing to update key information on their web pages.
There are a few different causes of the “Publishing Failed” error, but one in particular is linked to the Block Editor. The new WordPress editing interface relies on the REST API to create, save, and publish posts. In the event that something is blocking or disabling this process on your site, you won’t be able to launch new content.
If you’re a beginner or just a less-technical user, any mention of the REST API can seem intimidating. However, in this case, there’s no need to worry.
All you need to understand for the purposes of resolving the “Publishing Failed” error is that the REST API is how the Block Editor communicates with WordPress.
When this communication is broken or disabled, the Block Editor’s publishing functionality breaks. If that is what’s causing the error on your site, you’ll need to get the REST API working again in order to fix it.
How to Fix the WordPress Updating Failed and Publishing Failed Errors (In 4 Steps)
Once you understand why your WordPress content is failing to update or publish, resolving the problem becomes easier. Here are four steps you can take to go about fixing this problem on your site.
Step 1: Determine Whether the REST API Is Being Blocked
A common cause of the “Publishing Failed” error in WordPress (since the Block Editor was launched) is that the REST API is being blocked or disabled. If you’re seeing this message, a wise place to start troubleshooting is by testing the REST API to make sure it’s working.
You can do this directly in WordPress using the Site Health tool. To access it, navigate to Tools > Site Health:
Under the Status tab, WordPress will list any existing problems with your installation. If the REST API is being blocked, you’ll see the following message:
“The REST API encountered an unexpected result.
The REST API is one way WordPress and other applications communicate with the server. One example is the block editor screen, which relies on this to display and save your posts and pages.”
The Site Health tool will also display a specific error that is producing the ‘unexpected result’. This could be a “401 Not Authorized” response, an operation timeout, a “403 Cookie Nonce Is Invalid” message, or another error.
How you should go about resolving this problem and enabling the REST API again will depend somewhat on the error you see listed here.
Step 2: Re-Enable the REST API by Resolving the Specified Error
Ideally, the Site Health tool will provide some indication as to how you can re-enable the REST API on your WordPress site. Some common solutions include:
- Checking to see if Cloudflare is blocking the REST API. If you’re a Cloudflare user, your firewall may be inadvertently blocking legitimate requests. Check your Rule Set to determine if the REST API is being blocked, and disable rules as necessary to let it through.
- Making sure a plugin is not blocking or disabling the REST API. Some plugins may block the REST API as well. Disabling your plugins one at a time can help you determine which one, if any, is causing the problem. You may then remove, replace, or change the settings for that plugin to enable the REST API again. Security and performance optimization plugins are common culprits.
- Authenticating your WordPress site with the REST API via your .htaccess file. The REST API requires your website to authenticate itself before it can connect. In the event that your site is not doing so, you can make a small edit to your .htaccess file to resolve this issue.
- Determining if the issue is server related. Some users have found that they encounter this problem when running WordPress on a Windows server. You’ll need to edit your web.config file to fix it.
Plugins and firewall applications are the source of the problem most of the time, so it would be wise to start your troubleshooting attempts there.
Chances are, you’ll be able to find the tool that’s causing the “Publishing Failed” error in WordPress and disable it or change its settings to resolve the issue.
Step 3: Enable Debugging Mode to Search for Errors
If you can’t re-enable the REST API using one of the solutions listed in Step 2, you can try turning on WordPress’ debug mode. This feature is meant for temporary use as a troubleshooting tool.
When activated, the debug mode will log all PHP responses in a file named debug.log in your site’s wp-content directory. You can search this file for errors that may be preventing WordPress from connecting to the REST API, and therefore from publishing or updating posts.
To activate debug mode, add the following code to your wp-config.php file before the line that reads “/* That’s all, stop editing! Happy blogging. */”:
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );Make sure to remove this code from wp-config.php once you’ve resolved the error.
As an alternative, Kinsta customers can access the error logs available in their MyKinsta dashboard.
To access yours, log in to your MyKinsta and navigate to the Sites tab:
Click on the name of the website experiencing the error in the resulting list. Then navigate to Logs and select error.log from the drop-down menu:
You should then see a list of any issues your WordPress site is currently experiencing.
Step 4: Install and Activate the Classic Editor Plugin as a Temporary Solution
In the unlikely event that the above steps are not helpful in resolving the “Publishing Failed” error in WordPress, you’ll likely need to seek support from one of the following sources:
- Your hosting provider if you believe the issue is related to your server or if your host provides WordPress support.
- A specific plugin or firewall application, such as Cloudflare, if you believe a tool that is integral to your site is blocking the REST API and you’re unable to remedy the problem yourself.
- The WordPress Support forums, if you feel you need further guidance, such as for a free plugin that does not provide user support.
While you work with a relevant support provider to resolve the “Publishing Failed” error, you may wish to install the Classic Editor plugin as a temporary workaround:
Since the TinyMCE editor does not require the use of the REST API to publish or update posts, you should be able to make the necessary changes to your content with it.
However, this is only a stopgap measure. You’ll still want to resolve the root cause of the error in the Block Editor and then re-enable it.
Is the annoying ‘Updating Failed’ or ‘Publishing Failed’ WordPress error preventing you from pushing new content live? That has to stop! Check out how to fix this issue with this guide 🎉💪Click to Tweet
Summary
Not being able to publish or update your WordPress site’s content can be a serious problem. Fortunately, there are a few common causes of these errors that you can quickly troubleshoot to put things back in order.
If you’re receiving an “Updating Failed” or “Publishing Failed” message in the WordPress Block Editor, try:
- Determining whether the REST API is being blocked.
- Re-enabling the REST API by resolving the specified error.
- Enabling debugging mode to search for errors.
- Installing and activating the Classic Editor plugin as a temporary solution.
Get all your applications, databases and WordPress sites online and under one roof. Our feature-packed, high-performance cloud platform includes:
- Easy setup and management in the MyKinsta dashboard
- 24/7 expert support
- The best Google Cloud Platform hardware and network, powered by Kubernetes for maximum scalability
- An enterprise-level Cloudflare integration for speed and security
- Global audience reach with up to 35 data centers and 275 PoPs worldwide
Test it yourself with $20 off your first month of Application Hosting or Database Hosting. Explore our plans or talk to sales to find your best fit.
If your WordPress site is returning an error message such as “Updating Failed” or “Publishing Failed” when you try to make changes, the results can be not only frustrating but can also prevent visitors from accessing what they need.
Fortunately, there are a few common causes and workarounds that can help you resolve this issue if you encounter it. With a little troubleshooting, you should be back to your regular posting schedule in no time.
In this article, we’ll discuss what causes the “Updating Failed” and “Publishing Failed” errors in WordPress. Then we’ll explain four ways you can fix or work around the problem, to get your content up for readers.
Let’s get to it!
Why WordPress Sometimes Fails to Update or Publish Content
The Block Editor has been around for a while now. It’s still being met with mixed reactions, however, and there are also new challenges and errors that WordPress users can face because of it.
One such issue is a message reading “Publishing Failed” in the WordPress editor:
This message may appear after you click on the blue Publish button, in an attempt to make your content live. A variation of this error is the “Updating Failed” message, which may show up when you attempt to make changes to a post or page that you’ve already published:
As you can imagine, this problem can be an especially frustrating one for bloggers, as well as any site owner who finds themselves needing to update key information on their web pages.
There are a few different causes of the “Publishing Failed” error, but one in particular is linked to the Block Editor. The new WordPress editing interface relies on the REST API to create, save, and publish posts. In the event that something is blocking or disabling this process on your site, you won’t be able to launch new content.
If you’re a beginner or just a less-technical user, any mention of the REST API can seem intimidating. However, in this case, there’s no need to worry.
All you need to understand for the purposes of resolving the “Publishing Failed” error is that the REST API is how the Block Editor communicates with WordPress.
When this communication is broken or disabled, the Block Editor’s publishing functionality breaks. If that is what’s causing the error on your site, you’ll need to get the REST API working again in order to fix it.
How to Fix the WordPress Updating Failed and Publishing Failed Errors (In 4 Steps)
Once you understand why your WordPress content is failing to update or publish, resolving the problem becomes easier. Here are four steps you can take to go about fixing this problem on your site.
Step 1: Determine Whether the REST API Is Being Blocked
A common cause of the “Publishing Failed” error in WordPress (since the Block Editor was launched) is that the REST API is being blocked or disabled. If you’re seeing this message, a wise place to start troubleshooting is by testing the REST API to make sure it’s working.
You can do this directly in WordPress using the Site Health tool. To access it, navigate to Tools > Site Health:
Under the Status tab, WordPress will list any existing problems with your installation. If the REST API is being blocked, you’ll see the following message:
“The REST API encountered an unexpected result.
The REST API is one way WordPress and other applications communicate with the server. One example is the block editor screen, which relies on this to display and save your posts and pages.”
The Site Health tool will also display a specific error that is producing the ‘unexpected result’. This could be a “401 Not Authorized” response, an operation timeout, a “403 Cookie Nonce Is Invalid” message, or another error.
How you should go about resolving this problem and enabling the REST API again will depend somewhat on the error you see listed here.
Step 2: Re-Enable the REST API by Resolving the Specified Error
Ideally, the Site Health tool will provide some indication as to how you can re-enable the REST API on your WordPress site. Some common solutions include:
- Checking to see if Cloudflare is blocking the REST API. If you’re a Cloudflare user, your firewall may be inadvertently blocking legitimate requests. Check your Rule Set to determine if the REST API is being blocked, and disable rules as necessary to let it through.
- Making sure a plugin is not blocking or disabling the REST API. Some plugins may block the REST API as well. Disabling your plugins one at a time can help you determine which one, if any, is causing the problem. You may then remove, replace, or change the settings for that plugin to enable the REST API again. Security and performance optimization plugins are common culprits.
- Authenticating your WordPress site with the REST API via your .htaccess file. The REST API requires your website to authenticate itself before it can connect. In the event that your site is not doing so, you can make a small edit to your .htaccess file to resolve this issue.
- Determining if the issue is server related. Some users have found that they encounter this problem when running WordPress on a Windows server. You’ll need to edit your web.config file to fix it.
Plugins and firewall applications are the source of the problem most of the time, so it would be wise to start your troubleshooting attempts there.
Chances are, you’ll be able to find the tool that’s causing the “Publishing Failed” error in WordPress and disable it or change its settings to resolve the issue.
Step 3: Enable Debugging Mode to Search for Errors
If you can’t re-enable the REST API using one of the solutions listed in Step 2, you can try turning on WordPress’ debug mode. This feature is meant for temporary use as a troubleshooting tool.
When activated, the debug mode will log all PHP responses in a file named debug.log in your site’s wp-content directory. You can search this file for errors that may be preventing WordPress from connecting to the REST API, and therefore from publishing or updating posts.
To activate debug mode, add the following code to your wp-config.php file before the line that reads “/* That’s all, stop editing! Happy blogging. */”:
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );Make sure to remove this code from wp-config.php once you’ve resolved the error.
As an alternative, Kinsta customers can access the error logs available in their MyKinsta dashboard.
To access yours, log in to your MyKinsta and navigate to the Sites tab:
Click on the name of the website experiencing the error in the resulting list. Then navigate to Logs and select error.log from the drop-down menu:
You should then see a list of any issues your WordPress site is currently experiencing.
Step 4: Install and Activate the Classic Editor Plugin as a Temporary Solution
In the unlikely event that the above steps are not helpful in resolving the “Publishing Failed” error in WordPress, you’ll likely need to seek support from one of the following sources:
- Your hosting provider if you believe the issue is related to your server or if your host provides WordPress support.
- A specific plugin or firewall application, such as Cloudflare, if you believe a tool that is integral to your site is blocking the REST API and you’re unable to remedy the problem yourself.
- The WordPress Support forums, if you feel you need further guidance, such as for a free plugin that does not provide user support.
While you work with a relevant support provider to resolve the “Publishing Failed” error, you may wish to install the Classic Editor plugin as a temporary workaround:
Since the TinyMCE editor does not require the use of the REST API to publish or update posts, you should be able to make the necessary changes to your content with it.
However, this is only a stopgap measure. You’ll still want to resolve the root cause of the error in the Block Editor and then re-enable it.
Is the annoying ‘Updating Failed’ or ‘Publishing Failed’ WordPress error preventing you from pushing new content live? That has to stop! Check out how to fix this issue with this guide 🎉💪Click to Tweet
Summary
Not being able to publish or update your WordPress site’s content can be a serious problem. Fortunately, there are a few common causes of these errors that you can quickly troubleshoot to put things back in order.
If you’re receiving an “Updating Failed” or “Publishing Failed” message in the WordPress Block Editor, try:
- Determining whether the REST API is being blocked.
- Re-enabling the REST API by resolving the specified error.
- Enabling debugging mode to search for errors.
- Installing and activating the Classic Editor plugin as a temporary solution.
Get all your applications, databases and WordPress sites online and under one roof. Our feature-packed, high-performance cloud platform includes:
- Easy setup and management in the MyKinsta dashboard
- 24/7 expert support
- The best Google Cloud Platform hardware and network, powered by Kubernetes for maximum scalability
- An enterprise-level Cloudflare integration for speed and security
- Global audience reach with up to 35 data centers and 275 PoPs worldwide
Test it yourself with $20 off your first month of Application Hosting or Database Hosting. Explore our plans or talk to sales to find your best fit.
Тема: REST API выдал ошибку (Прочитано 8195 раз)
0 Пользователей и 1 Гость просматривают эту тему.
Reply
В админке в Здоровье сайта появились такие критические ошибки:
REST API выдал ошибку
REST API — один из способов коммуникации WordPress и других приложений с сервером. К примеру, экран редактора блоков использует его для отображения и сохранения ваших записей и страниц.
Запрос к REST API неудачен из-за ошибки.
Ошибка: cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received (http_request_failed)
Ваш сайт не смог выполнить петлевой запрос
Петлевые запросы используются для запуска запланированных заданий, а также используются встроенным редактором кода плагинов и тем для проверки корректности кода.
Петлевой запрос к вашему сайту не удался. Возможности, зависящие от его работоспособности, не могут работать так, как должны.
Ошибка: cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received (http_request_failed)
Долго не мог понять в чем дело, обновил плагины, тему (у меня дефолтная), одна ошибка пропала, потом появилась снова. 
Но потом разобрался! Главное не верьте даунам, которые пыхтят о том, что это распространённая ошибка которая связана с сервером. 
И что в большинстве случаев она не вызывается ни какой-либо темой, ни плагином, и не самим WordPress.
Что надо дергать хостинг, переходить на ВПС, увеличить лимит и прочую байду!
Это особенно смешно читать, когда на хосте стоит несколько сайтов на WP, но именно один выдает такие ошибки!
Короче, дело не в сервере, никуда переходить и никого дергать не нужно!
Дело именно ваших плагинах, поскольку это REST API тесно с ними связано. Попробуйте отключать плагины по одному и смотреть что получится. В моем случае это был плагин капчи CheckBot, может быть виновать также плагин WP Limit Login Attempts и другие…
В общем проверяйте сами, а то в интернете сейчас полно умников, которые как чукча, только пейсатели, но ни куя не веб-мастера!
Дмитрий
Здравствуйте. Ваши рекомендации реально помогли! Всё, что я читал на других сайтах не работало. А пробовал я практически всё, что писали. Потерял кучу времени, результат ноль!
Но хорошо, что я попал к Вам на сайт и прочитал отличные рекомендации по поводу отключения плагинов!
На моём сайте, «косяки» были из-за плагина калькулятор. Название: wp-creator-calculator
Спасибо за помощь! Удачи в жизни!
Максим
Большое Спасибо!! Вы очень помогли !!!!
Пожалуйста. 
Арсений
То есть плагины в прямом смысле удалять? Или можно другим способом сделать?
Не удалять, а отключать по одному в админке и смотреть на результат.
Elskazi
И правда, помогло, а если этот плагин нужен?
Лилия
Reply, респект. У меня это оказался плагин контактной формы. Спасибо 
Галин
Всем добрый вечер! У меня та же проблема вылезла. Отключение плагинов по одному не решило проблемы. Что может быть ещё? И как это устранить? Может, кто-то подскажет? Спасибо.
Добрый день.
Такая проблема — это «REST API выдал ошибку»?
Приведите, пожалуйста, текст ошибки/ошибок полностью.
Ali
После отключение плагинов по одному и проверяя, вот результат, сайт перестал загружается.
Warning: Use of undefined constant WPFDL_PLUGIN_FILE — assumed ‘WPFDL_PLUGIN_FILE’ (this will throw an Error in a future version of PHP) in /home/admin/web/itop7.ru/public_html/wp-content/plugins/wp-table-manager-light/wp-table-manager-light.php on line 47
Warning: include_once(.//framework/ju-libraries.php): failed to open stream: No such file or directory in /home/admin/web/itop7.ru/public_html/wp-content/plugins/wp-table-manager-light/wp-table-manager-light.php on line 47
Warning: include_once(): Failed opening ‘.//framework/ju-libraries.php’ for inclusion (include_path=’.:/usr/share/php’) in /home/admin/web/itop7.ru/public_html/wp-content/plugins/wp-table-manager-light/wp-table-manager-light.php on line 47
Fatal error: Uncaught Error: Class ‘JoomunitedWPFrameworkv1_0_4Application’ not found in /home/admin/web/itop7.ru/public_html/wp-content/plugins/wp-table-manager-light/wp-table-manager-light.php:65 Stack trace: #0 /home/admin/web/itop7.ru/public_html/wp-settings.php(388): include_once() #1 /home/admin/web/itop7.ru/public_html/wp-config.php(91): require_once(‘/home/admin/web…’) #2 /home/admin/web/itop7.ru/public_html/wp-load.php(37): require_once(‘/home/admin/web…’) #3 /home/admin/web/itop7.ru/public_html/wp-blog-header.php(13): require_once(‘/home/admin/web…’) #4 /home/admin/web/itop7.ru/public_html/index.php(17): require(‘/home/admin/web…’) #5 {main} thrown in /home/admin/web/itop7.ru/public_html/wp-content/plugins/wp-table-manager-light/wp-table-manager-light.php on line 65
На сайте возникла критическая ошибка.
Прочитайте эту статью про отладку в WordPress, для того, чтобы найти источник проблемы на вашем сайте.
- Ответ
- Печать
Страницы: [1] 2 Вверх
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
-
Posts
-
Something is blocking the API integration with DHL Express Commerce and I’ve done everything I can think of to troubleshoot. I’ve deactivated every plugin on our site and it does not resolve the API issue and it does not resolve ‘The REST API did not process the context query parameter correctly’ error shown in my site health test. Please help.
WP.com: Unknown
Jetpack: Yes
Correct account: YesThe blog I need help with is: (visible only to logged in users)
Hi there,
You’re posting in the support forums for the hosting provider, WordPress.com. The site you indicated above is not hosted with us, but using the open source WordPress software at another host. It’s just connected to your WordPress.com account via the Jetpack plugin. We also don’t offer any DHL API integration on WordPress.com.
I’m guessing you’re using a plugin to integrate with that API, correct? In that case tupport for that plugin are the best people to help you with this.
Of if this is a custom integration you built for your site, you’ll probably want to contact support at DHL Express Commerce directly instead.
Thank you for your response. DHL was just the example that brought my attention to the API issue. I’m not using a DHL plugin or anything. When I run a site health check in wordpress, I get an error saying “The Rest API did not behave correctly – The REST API did not process the context query parameter correctly.” I’ve disabled all of my plugins and reset my default theme to twenty twentyone still get this error message. So, I’ve ruled out all plugins or Theme conflicts.
Oct 22, 2021 at 10:45 am
#3751253
Hello there,
Looking at this thread here: https://wordpress.org/support/topic/page-post-updating-failed-wordpress-5-2-rest-api-context-query-parameter/
It looks like a place to start would be to check permalinks and perhaps try setting them to Plain.
I hope this helps.
- The topic ‘The REST API did not process the context query parameter correctly.’ is closed to new replies.