Что такое json rest

Что такое json rest

17 августа 2017

Что такое REST?

REST — (сокр. от англ. Representational State Transfer — «передача состояния представления») архитектурный стиль взаимодействия компонентов распределённого приложения в сети по модели клиент-сервер. Был разработан в диссертации Роя Филдинга в 200 году, как альтернатива SOAP, когда запрос клиента несет в себе исчерпывающую информацио о желаемом ответе сервера и сервер не обязан сохранять сессию взаимодействия с клиентом.

Особенности архитектурного стиля:

  • Каждая сущность должна иметь уникальный идентификатор – URI.
  • Сущности должны быть связаны между собой.
  • Для чтения и изменения данных должны использоваться стандартные методы.
  • Должна быть поддержка нескольких типов ресурсов.
  • Взаимодействие должно осуществляться без состояния.

Стандартные методы таковы:

  • GET – получение данных без их изменения. Это наиболее популярный и легкий метод. Он только возвращает данные, а не изменяет их, поэтому на клиенте вам не нужно заботиться о том, что вы можете повредить данные.
  • POST – метод, подразумевающий вставку новых записей.
  • PUT – метод, подразумевающий изменение существующих записей.
  • PATCH – метод, подразумевающий изменение идентификатора существующих записей.
  • DELETE – метод, подразумевающий удаление записей.

Что такое REST-API?

REST API – это набор удаленных вызовов стандартных методов, возвращающих данные в определенном формате.

Где используется стиль REST в Android?

1) См. реализации различных библиотек REST-клиентов, например: Retrofit, Volley, RoboSpice… См. статью Volley vs Retrofit

Задачи, которые требуется решить при реализации REST-клиента

Перечислим, какие основные задачи придется решать при реализации REST-клиента на Android согласно паттернам Virgil Dobjanschi (Это так называемые паттерны A/B/C, которые описывают способы реализации REST-клиента под Android. Подробней о паттернах на русском можно глянуть здесь (лекция 2) или здесь):

  • Управление сервисом: запуск, остановка.
  • Передача результатов из сервиса в активити.
  • Кэшировать результатов в sqlite.
  • Фиксирование статуса данных sqlite перед и после выполнения REST-запроса.
  • Запись информации о проводимых REST-операциях в sqlite.
  • Парсинг полученных данных.
  • Конструирование REST-запроса на основе URI и набора параметров.
  • Выполнение сетевых запросов к REST-серверу.
  • Чистка базы данных от устаревших данных.
  • В случае неудачи REST-запроса, пытаться повторить запрос (например, экспоненциально увеличивая время между запросами).
  • Возможность отложенного запуска REST-запроса через SyncAdapter.

Некоторые важные моменты для реализации REST-клиента под Android, согласно паттернам A/B/C

  • Данные, полученные от REST-сервера, всегда сохраняются в sqlite. Напрямую в Activity они никогда не передаются. Вместо этого в Activity передается уведомление о том, что данные загружены в sqlite и их можно оттуда загрузить (вариант — Activity получает уведомление об обновлении данных в Content Provider через Content Observer).
  • При выполнении операций insert, delete, update данные в sqlite обновляются дважды: первый раз до отправки REST-запроса, второй раз — после получения результата. Первая операций выставляет информационные флаги, сигнализирующие о типе операции, проводимой над данными, и о статусе операции.
  • REST-методы следует всегда выполнять в отдельном потоке.
  • Следует использовать Apache HTTP client, а не Java URL connection.
  • Форматы данных в порядке предпочтения: какой-либо бинарный формат (например, AMF3), затем JSON, затем XML.
  • Желательно включать gzip. GZip на Android реализован “нативно”, библиотека быстрая. В некоторых случаях можно получить коэффициент сжатия 5:1 и даже 10:1, в зависимости от количества получаемых данных. Использование GZip ускоряет загрузку данных и экономит батарею.
  • Если используете Sqlite — используйте транзакции.
  • Если программе требуется скачать 10-20 картинок, не стоит запускать 10-20 параллельных закачек. Запускайте 1-3, а остальные ставьте в очередь.
  • Activity регистрирует binder callback (т.е. ResultReceiver), для получения ответа от сервиса. Этот callback нужно обязательно удалить при вызове onPause у Activity, иначе можно налететь на ANR.
  • Длительные операции всегда следует запускать из сервиса. Сервис обязательно следует останавливать после того, как требуемые операции выполнены.
  • Необходимо минимизировать сетевой трафик.
  • Следует разбивать данные на страницы (конечно, если REST Api предоставляют такую возможность).
  • Для некритичной по времени синхронизации данных между клиентом и сервером рекомендуется использовать SyncAdapter.

Алгоритм фомирования запроса к серверу

В общем случае, при выполнении запроса к REST-серверу, требуется выполнить ряд операций:

  • сформировать URL
  • задать HTTP-заголовки
  • выбрать тип HTTP-запроса
  • сформировать тело HTTP-запроса, т.е. преобразовать Java объект в JSON
  • выполнить запрос, воспользовавшись HTTP-клиентом
  • распарсить результаты запроса — преобразовать полученный JSON в Java объект

REST (от англ. Representational State Transfer — «передача состояния представления») — архитектурный стиль взаимодействия компонентов распределённого приложения в сети. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиа-системы. В определённых случаях (интернет-магазины, поисковые системы, прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле [ уточнить ] компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине. REST является альтернативой RPC [1] .

В сети Интернет вызов удалённой процедуры может представлять собой обычный HTTP-запрос (обычно «GET» или «POST»; такой запрос называют «REST-запрос»), а необходимые данные передаются в качестве параметров запроса [2] [3] .

Для веб-служб, построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».

В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API. Дело в том, что REST является архитектурным стилем, в то время как SOAP является протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство RESTful-реализаций используют такие стандарты, как HTTP, URL, JSON и XML.

Содержание

История термина [ править | править код ]

Хотя данная концепция лежит в самой основе Всемирной паутины, термин «REST» был введён Роем Филдингом (англ. Roy Fielding ), одним из создателей протокола «HTTP», лишь в 2000 году [3] . В своей диссертации «Архитектурные стили и дизайн сетевых программных архитектур» («Architectural Styles and the Design of Network-based Software Architectures») [4] в Калифорнийском университете в Ирвайне [2] он подвёл теоретическую основу под способ взаимодействия клиентов и серверов во Всемирной паутине, абстрагировав его и назвав «передачей представительного состояния» («Representational State Transfer»). Филдинг описал концепцию построения распределённого приложения, при которой каждый запрос (REST-запрос) клиента к серверу содержит в себе исчерпывающую информацию о желаемом ответе сервера (желаемом представительном состоянии), и сервер не обязан сохранять информацию о состоянии клиента («клиентской сессии»).

Читайте также:  Игры самсунг gt e2232

Стиль «REST» развивался параллельно с «HTTP 1.1», разработанным в 1996—1999 годах, основываясь на существующем дизайне «HTTP 1.0», разработанном в 1996 году [5] .

Свойства Архитектуры REST [ править | править код ]

Свойства архитектуры, которые зависят от ограничений, наложенных на REST-системы:

  • Производительность — взаимодействие компонентов системы может являться доминирующим фактором производительности и эффективности сети с точки зрения пользователя;
  • Масштабируемость для обеспечения большого числа компонентов и взаимодействий компонентов.

Рой Филдинг — один из главных авторов спецификации протокола HTTP, описывает влияние архитектуры REST на масштабируемость следующим образом:

  • Простота унифицированного интерфейса;
  • Открытость компонентов к возможным изменениям для удовлетворения изменяющихся потребностей (даже при работающем приложении);
  • Прозрачность связей между компонентами системы для сервисных служб;
  • Переносимость компонентов системы путем перемещения программного кода вместе с данными;
  • Надёжность, выражающаяся в устойчивости к отказам на уровне системы при наличии отказов отдельных компонентов, соединений или данных. [2]

Требования к архитектуре REST [ править | править код ]

Существует шесть обязательных ограничений для построения распределённых REST-приложений по Филдингу [2] [6] .

Выполнение этих ограничительных требований обязательно для REST-систем [7] [8] . Накладываемые ограничения определяют работу сервера в том, как он может обрабатывать и отвечать на запросы клиентов. Действуя в рамках этих ограничений, система приобретает такие желательные свойства как производительность, масштабируемость, простота, способность к изменениям, переносимость, отслеживаемость и надёжность.

Если сервис-приложение нарушает любое из этих ограничительных условий, данную систему нельзя считать REST-системой [2] .

Обязательными условиями-ограничениями являются:

1. Модель клиент-сервер [ править | править код ]

Первым ограничением, применимым к гибридной модели, является приведение архитектуры к модели клиент-сервер. Разграничение потребностей является принципом, лежащим в основе данного накладываемого ограничения. Отделение потребности интерфейса клиента от потребностей сервера, хранящего данные, повышает переносимость кода клиентского интерфейса на другие платформы, а упрощение серверной части улучшает масштабируемость. Наибольшее же влияние на всемирную паутину, пожалуй, имеет само разграничение, которое позволяет отдельным частям развиваться независимо друг от друга, поддерживая потребности в развитии интернета со стороны различных организаций. [2]

2. Отсутствие состояния [ править | править код ]

Протокол взаимодействия между клиентом и сервером требует соблюдения следующего условия: в период между запросами клиента никакая информация о состоянии клиента на сервере не хранится (Stateless protocol или «протокол без сохранения состояния»). Все запросы от клиента должны быть составлены так, чтобы сервер получил всю необходимую информацию для выполнения запроса. Состояние сессии при этом сохраняется на стороне клиента [2] . Информация о состоянии сессии может быть передана сервером какому-либо другому сервису (например, в службу базы данных) для поддержания устойчивого состояния, например, на период установления аутентификации. Клиент инициирует отправку запросов, когда он готов (возникает необходимость) перейти в новое состояние.

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

3. Кэширование [ править | править код ]

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

4. Единообразие интерфейса [ править | править код ]

Наличие унифицированного интерфейса является фундаментальным требованием дизайна REST-сервисов [2] . Унифицированные интерфейсы позволяют каждому из сервисов развиваться независимо.

К унифицированным интерфейсам предъявляются следующие четыре ограничительных условия [9] [10] :

  • Все ресурсы идентифицируются в запросах, например, с использованием URI в интернет-системах. Ресурсы концептуально отделены от представлений, которые возвращаются клиентам. Например, сервер может отсылать данные из базы данных в виде HTML, XML или JSON, ни один из которых не является типом хранения внутри сервера.

Манипуляция ресурсами через представление

  • Если клиент хранит представление ресурса, включая метаданные — он обладает достаточной информацией для модификации или удаления ресурса.
  • Каждое сообщение содержит достаточно информации, чтобы понять, каким образом его обрабатывать. К примеру, обработчик сообщения (parser), необходимый для извлечения данных, может быть указан в списке MIME-типов[2] .

Гипермедиа как средство изменения состояния приложения (HATEOAS)

  • Клиенты изменяют состояние системы только через действия, которые динамически определены в гипермедиа на сервере (к примеру, гиперссылки в гипертексте). Исключая простые точки входа в приложение, клиент не может предположить, что доступна какая-то операция над каким-то ресурсом, если не получил информацию об этом в предыдущих запросах к серверу. Не существует универсального формата для предоставления ссылок между ресурсами, RFC 5988 и JSON Hypermedia API Language являются двумя популярными форматами предоставления ссылок в REST HYPERMEDIA сервисах.

5. Слои [ править | править код ]

Клиент обычно не способен точно определить, взаимодействует он напрямую с сервером или же с промежуточным узлом, в связи с иерархической структурой сетей (подразумевая, что такая структура образует слои). Применение промежуточных серверов способно повысить масштабируемость за счёт балансировки нагрузки и распределённого кэширования. Промежуточные узлы также могут подчиняться политике безопасности с целью обеспечения конфиденциальности информации [11] .

6. Код по требованию (необязательное ограничение) [ править | править код ]

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

Преимущества [ править | править код ]

Филдинг указывал, что приложения, не соответствующие приведённым условиям, не могут называться REST-приложениями. Если же все условия соблюдены, то, по его мнению, приложение получит следующие преимущества [2] [6] :

  • Надёжность (за счёт отсутствия необходимости сохранять информацию о состоянии клиента, которая может быть утеряна);
  • Производительность (за счёт использования кэша);
  • Масштабируемость;
  • Прозрачность системы взаимодействия (особенно необходимая для приложений обслуживания сети);
  • Простота интерфейсов;
  • Портативность компонентов;
  • Лёгкость внесения изменений;
  • Способность эволюционировать, приспосабливаясь к новым требованиям (на примере Всемирной паутины).
Читайте также:  При работающем светофоре знаки приоритета не действуют

Каждое понятие ниже играет важную роль в понимании WordPress REST API. Давайте ознакомимся с понятиями и фразами, которые используются в этом руководстве, чтобы иметь представление о чем речь. Подробнее каждое понятие прямо или косвенно рассмотрено в других разделах этого руководства.

Это простой и удобный формат данных, который выглядит как объект в JavaScript, отсюда и название (JavaScript Object Notation). Пример JSON формата:

REST получает и отдает JSON. Это позволяет разработчикам создавать, читать и обновлять контент WordPress с клиентского JavaScript или из внешних приложений, написанных на любом языке программирования.

HTTP Клиент (или просто Клиент)

Инструмент, который используется для взаимодействия с REST API. Этот инструмент позволяет создавать HTTP запросы и умеет обрабатывать полученные ответы.

Таким инструментом может быть:

  • Postman — программа или расширение для Chrome.
  • REST Easy — расширение для Firefox для тестирования запросов в браузере
  • httpie — тестирование запросов в командной строке.
  • WordPress HTTP API — клиент самого WordPress. Его, например, можно использовать для доступа к одному сайту WordPress с другого.

меню

Маршруты и Эндпоинты

Маршрут (Route — роут) — это «имя», которое отсылает работу API к определенным эндпоинтам. Если упростить, то можно сказать, что маршрут — это URL к которому можно обратиться разными HTTP методами. Маршрут может иметь несколько эндпоинтов.

  • Эндпоинт (Endpoint — конечная точка) — это само обращение к маршруту отдельным HTTP методом. Эндпоинт выполняют конкретную задачу, принимают параметры и возвращают данные Клиенту.
  • Пример

    Возьмем URL http://example.com/wp-json/wp/v2/posts/123 :

    • Маршрут здесь это wp/v2/posts/123 – маршрут не включает /wp-json/ , потому что это базовый путь самого REST API.
    • Этот маршрут имеет 3 эндпоинта:
    • GET — запускает метод get_item() и возвращает данные поста Клиенту.
    • PUT|PATCH|POST — запускает метод update_item() , обновляет данные и возвращает их Клиенту.
    • DELETE — запускает метод delete_item() , удаляет пост и возвращает только что удаленные данные Клиенту.
    Еще пример

    Если сделать GET запрос к корневому маршруту http://example.com/wp-json/ , мы получим JSON ответ, в котором видно какие доступны маршруты, и какие доступны эндпоинты для каждого маршрута. При этом маршрут тут это / (корень), а при GET запросе он становится эндпоинтом (конечной точкой).

    Заметка: на сайтах без включенных ЧПУ маршрут добавляется в URL в качестве параметра rest_route . В приведенном выше примере полный URL-адрес будет таким: http://example.com/?rest_route=wp/v2/posts/123

    Пространство имён — это начальная часть маршрута (префикс маршрута). Например, у WP есть маршрут wp/v2/posts , wp/v2 тут — это пространство имён.

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

    Пространство имени должно состоять из двух частей: vendor/package , где vendor — это поставщик (например название плагина или темы), а package — это версия кода указанного поставщика.

    Для примера возьмем префикс WP — wp/v2 :

    • wp — это первая часть — определяет имя модуля. Например, для плагина, там нужно указывать название плагина.
    • v2 — это вторая часть — определяет версию модуля. Например у WordPress была первая версия v1 , но с расширением REST API код кардинально изменился и так появилась v2 . Также может быть и с плагином, например, он писался и все было хорошо, пока не появились новые задачи и новый функционал, который несовместим со старой версией. И вот разработчик решает не улучшать текущую версию, а делать новую. Но при этом нужна обратная совместимость, чтобы старая версия работала как и прежде. Для этого создается новое пространство имени с v2 и туда пишется новый функционал, а старый v1 работает как работал.

    Еще одно преимущество использования пространства имён — это то, что Клиенты смогут обнаружить ваше произвольное API. Список пространств отображается по главному запросу на корневой URL REST API:

    При регистрации произвольных маршрутов настоятельно рекомендуется указывать пространство имени!

    Если вам нужно интегрироваться в пространство имени WP, то для создаваемого маршрута, можно указать пространство wp/v2 . Однако делать это нужно с пониманием дела!

    Что если не указать пространство имени?

    Допустим мы хотим иметь маршрут /books . Регистрируем его с помощью register_rest_route(), в результате получаем такой URL маршрута: http://example.com/wp-json/books . Маршрут будет работать, но это плохая практика, поскольку мы в конечном итоге загрязняем потенциальные маршруты API!

    Например, что если и другой плагин сделает тоже самое, тогда мы получим конфликт и один из маршрутов перестанет работать! Да, есть четвертый логический параметр register_rest_route() , который позволяет указать нужно ли перезаписывать существующий маршрут с таким же называнием, но это лишь лечение симптомов, а не болезни. Пространства имён позволяет не допускать подобных болезней.

    Сокращение от Create, Read, Update, Delete. Это короткое название всех видов операций маршрута, которые он позволяет делать: читать, создавать, обновлять и удалять что-либо (ресурс).

    Ресурсы — это сущности в WordPress — это Посты, Страницы, Комментарии, Юзеры, Элементы таксономий (термины) и т.д.

    WP-API позволяет HTTP-клиентам выполнять CRUD операции с ресурсами (create, read, update, delete).

    Пример того, как REST API взаимодействует с ресурсами:

    Путь к ресурсу — это имя ресурса в маршруте. Путь к ресурсу должен указывать, с каким ресурсом связана конечная точка. Например возьмем маршруты: wp/v2/posts и wp/v2/posts/ , тут путь к ресурсу будет /posts . Чтобы избежать конфликтов, путь к ресурсу должен быть уникальным в пределах текущего пространства имени.

    Читайте также:  Стиральная машина lg не может отжать

    Допустим, у нас есть плагин для интернет магазина и у него есть два основных типа ресурсов: заказы (на продукты) и продукты. Эти ресурсы связаны между собой, но это не одно и то же, и поэтому каждый из них должен «жить» по отдельному пути. Так, наши маршруты могут выглядеть следующим образом: /my-shop/v1/orders и /my-shop/v1/products .

    Один из основных классов в структуре WordPress REST API это WP_REST_Request. Этот класс используется для получения информации из запроса.

    Запрос может быть отправлен удаленно через HTTP или внутренне из PHP. Объекты WP_REST_Request создаются автоматически при каждом запросе HTTP к маршруту. Данные, указанные в запросе определяют, какой ответ будет получен.

    Ответ — это данные которые вернуться из API в ответ на запрос. Ответы от конечных точек управляются классом WP_REST_Response. Класс предоставляет разные способы взаимодействия с данными ответа.

    Ответы могут возвращать разные данные, в том числе JSON объект ошибки:

    В заголовках ответа также указывается его статус код (200, 401). В REST API статус код часто важен, на его основе можно понять что не так с запросом. Подробнее про статус коды смотрите в отдельном разделе.

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

    Методы которые используются в WP API:

    • GET — используются для получения (чтения) ресурсов (например постов).
    • POST — для создания ресурсов.
    • POST/PUT/PATCH — для обновления ресурсов.
    • DELETE — для удаления ресурсов.
    • OPTIONS — для получения полного описания маршрута.

    Не все клиенты поддерживают все эти методы или может быть на сервере установлен фаервол, который запрещает некоторые методы.

    Поэтому в WP API есть возможность указать такой метод по-другому:

    • в параметре запроса _method.
    • или в заголовке запроса X-HTTP-Method-Override .

    Например, если нужно удалить ресурс, но для Клиента невозможно указать метод DELETE , то запрос можно отправить методом GET или POST, а сам метод передать в URL так: /wp-json/my-shop/v1/products/1?_method=DELETE . _method параметр имеет больший приоритет над реальным методом запроса и в этом случае WP API будет обрабатывать запрос как если бы он был отправлен методом DELETE .

    Схема в REST API — это полное описание маршрута, оно рассказывает нам о маршруте все:

    • Какие в маршруте используются методы (GET POST).
    • Какие у него есть эндпоинты (конечные точки),
    • Какие у эндпоинта могут быть параметры.
    • Какими методами можно обращаться к эндпоинту.
    • Какую схему имеет ресурс (пост, коммент), с которым работает маршрут. Схема ресурса показывает какие будут возвращены поля при ответе на запрос при том или ином контексте.

    Под словом «схема» можно понимать разные Схемы. В общем смысле — это Схема маршрута — это общая схема всего маршрута, в которую входят две схемы:

    • Схемы эндпоинтов — это то какими методами можно обращаться к эндпоинту и то какие ему можно передать параметры. Таких схем у маршрута обычно несколько.
    • Схема ресурса — это поля (данные) из которых состоит ресурс. Например, пост состоит из: заголовка, контента, даты и т.д.

    В WP API схема представлена в виде JSON объекта и получить его можно сделав OPTIONS запрос на маршрут. Схема предоставляет машиночитаемые данные, поэтому любой Клиент который умеет читать JSON может понять с какими данными ему предстоит работать.

    Рассмотрим пример

    Возьмем маршрут /wp/v2/categories и посмотрим его схему:

    Схемы эндпоинтов:

    В ключе endpoints мы видим «Схемы эндпоинтов», т.е. какие у маршрута есть конечные точки. Их тут две: GET (получит рубрики) и POST (создаст рубрику). И тут же описаны все возможные параметры для этих конечных точек.

    Вот код схемы одного эндпоинта из кода выше (этот эндпоинт создает рубрику):

    Схема ресурса:

    В ключе schema мы видим «Схему ресурса», т.е. все аргументы JSON объекта, которые вернет API в случае удачного CRUD запроса.

    Так выглядит схема ресурса (рубрики) из кода выше:

    Вот более читаемый вариант схемы ресурса (рубрики) из кода выше:

    Параметр Контекст Описание
    id
    число
    view, edit, embed ID термина (рубрики).
    Только для чтения.
    count
    число
    view, edit Количество записей находящихся в термине (рубрике).
    Только для чтения.
    description
    строка
    view, edit Описание термина (рубрики).
    link
    строка, uri
    view, edit, embed URL термина (рубрики).
    Только для чтения.
    name
    строка
    view, edit, embed Название термина (рубрики).
    slug
    строка
    view, edit, embed Слаг (ярлык) термина (рубрики), обычно создается из названия.
    taxonomy
    строка
    view, edit, embed Название таксономии.
    Только для чтения.
    Может быть: category , post_tag , nav_menu , link_category , post_format
    parent
    число
    view, edit ID родительского термина.
    meta
    объект
    view, edit Мета поля.

    Контекст в схеме

    Контекст — показывает какие поля объекта вернуться в ответе при создании запроса в указанном контексте. Например, при обновлении или создании рубрики вернуться поля соответствующие контексту edit.

    Это процесс выяснения любых деталей о работе с REST API. Например:

    • Клиент может попытаться «обнаружить» включен ли вообще REST API на сайте. См. Обнаружение REST API.
    • Клиент может прочитать Схему маршрута и понять, какие у него есть конечные точки и какая у него схема ресурса.

    Это PHP класс созданный по разработанному разработчиками WP стандарту WP_REST_Controller .

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

    Концепция контроллера принята в рамках WP-API для того, чтобы иметь стандартный шаблон для классов контроллера — классов представляющих ресурсы (конечные точки). Шаблоном класса контроллера является абстрактный класс WP_REST_Controller. Каждый класс контроллера должен иметь аналогичную схему методов, сделано так для того, чтобы все конечные точки имели одинаковые названия PHP методов.

    Подробнее читайте в разделе Классы контроллеров!

    Ссылка на основную публикацию
    Что написать о себе в инстаграмме девушке
    Вроде как и всё ясно, но в самом деле, как только доходит до дела, написать о себе в Инстаграм, у...
    Чем открыть cab файл на компьютере
    Файл формата CAB открывается специальными программами. Чтобы открыть данный формат, скачайте одну из предложенных программ. Чем открыть файл в формате...
    Чем открыть fb2 на телефоне
    Формат электронных публикаций FB2, наряду с EPUB и MOBI, является одним из самых популярных для книг, публикуемых в интернете. Мы...
    Что нового в айос 12 1
    Apple выпустила iOS 12.1.1 − скорее всего, последнюю публичную сборку iOS 12 в этом году. Хотя это обновление по большей...
    Adblock detector