Что такое сетевой контроллер?
Сетевой контроллер является краеугольным камнем управления программно-конфигурируемой сетью (SDN). Это высокомасштабируемая роль сервера, которая предоставляет централизованную программируемую точку автоматизации для управления, настройки, мониторинга и устранения неполадок инфраструктуры виртуальной сети.
С помощью сетевого контроллера можно автоматизировать настройку сетевой инфраструктуры и управление ею, а не выполнять настройку сетевых устройств и служб вручную.
Принцип работы сетевого контроллера
Сетевой контроллер предоставляет один программный интерфейс (API), который позволяет сетевому контроллеру взаимодействовать с сетевыми устройствами, службами и компонентами и управлять ими (SOUTHBOUND API), и второй API, позволяющий приложениям управления сообщать сетевому контроллеру, какие сетевые параметры и службы им нужны (СЕВЕРНЫЙ API).
С помощью ЮЖНОГО API сетевой контроллер может управлять сетевыми устройствами и сетевыми службами, а также собирать все необходимые сведения о сети. Сетевой контроллер постоянно отслеживает состояние сетевых устройств и служб и обеспечивает исправление любого отклонения конфигурации от требуемого состояния.
Северный API-интерфейс сетевого контроллера реализован как интерфейс REST. Она предоставляет возможность управлять сетью центра обработки данных из приложений управления. Для управления пользователи могут напрямую использовать REST API или Windows PowerShell, созданные на основе REST API, или приложения управления с графическим пользовательским интерфейсом, например Windows Admin Center или System Center Virtual Machine Manager.
Дополнительные сведения об этих командлетах PowerShell см. в справочнике по NetworkController .
Функции сетевого контроллера
Сетевой контроллер позволяет управлять функциями SDN, такими как виртуальные сети, брандмауэры, Load Balancer программного обеспечения и шлюз RAS. Ниже приведены некоторые из его многочисленных функций.
Управление виртуальной сетью
Эта функция сетевого контроллера позволяет развертывать и настраивать виртуализацию сети Hyper-V, настраивать виртуальные сетевые адаптеры на отдельных виртуальных машинах, а также хранить и распространять политики виртуальной сети. С помощью этой функции можно создавать виртуальные сети и подсети, подключать виртуальные машины к этим сетям и разрешать обмен данными между виртуальными машинами в одной виртуальной сети.
Сетевой контроллер поддерживает сети на основе виртуальной локальной сети (VLAN), сетевую инкапсуляцию универсальной маршрутизации (NVGRE) и виртуальную расширяемую локальную сеть (VXLAN).
Управление брандмауэром
Эта функция сетевого контроллера позволяет настраивать и администрировать правила разрешения и запрета брандмауэра контроль доступа для виртуальных машин рабочей нагрузки для внутреннего (восточного и западного) и внешнего (север и юг) сетевого трафика в центре обработки данных. Правила брандмауэра размещаются в порту vSwitch виртуальных машин рабочей нагрузки, поэтому они распределяются между рабочими нагрузками в центре обработки данных и перемещаются вместе с рабочими нагрузками.
С помощью API Northbound можно определить правила брандмауэра для входящего и исходящего трафика с виртуальных машин рабочей нагрузки. Также можно создать отдельное правило брандмауэра для внесения в журнал всех данных, пропущенных или отклоненных в соответствии с правилами.
Управление Load Balancer программного обеспечения
Программное Load Balancer позволяет разрешить нескольким серверам размещать одну и ту же рабочую нагрузку, обеспечивая высокий уровень доступности и масштабируемости. С помощью программного Load Balancer можно настраивать балансировку нагрузки, преобразование сетевых адресов (NAT) входящего трафика (NAT) и исходящий доступ к Интернету для рабочих нагрузок, подключенных к традиционным сетям виртуальных локальных сетей и виртуальным сетям.
Управление шлюзом
Шлюз службы удаленного доступа (RAS) позволяет развертывать, настраивать и администрировать виртуальные машины, которые являются членами пула шлюзов, обеспечивая внешнее сетевое подключение к рабочим нагрузкам клиента. При использовании шлюзов между виртуальными и удаленными сетями поддерживаются следующие типы подключений:
- Подключение шлюза виртуальной частной сети типа «сеть — сеть» (VPN) с помощью IPsec
- Подключение VPN-шлюза типа «сеть — сеть» с использованием универсальной инкапсуляции маршрутизации (GRE)
- Возможность перенаправления уровня 3
Подключения шлюза поддерживают протокол BGP для динамического управления маршрутами.
Цепочка виртуальных (модуль)
Эта функция сетевого контроллера позволяет подключать виртуальные сетевые устройства к виртуальным сетям. Эти устройства можно использовать для расширенного брандмауэра, балансировки нагрузки, обнаружения и предотвращения вторжений и многих других сетевых служб. Вы можете добавить виртуальные устройства, которые выполняют определяемые пользователем функции маршрутизации и зеркального отображения портов. При определяемой пользователем маршрутизации виртуальная (модуль) используется в качестве маршрутизатора между виртуальными подсетями в виртуальной сети. При зеркальном отображении портов весь сетевой трафик, который входит в отслеживаемый порт или покидает его, дублируется и отправляется на виртуальную (модуль) для анализа.
Дополнительные сведения о определяемых пользователем маршрутах см. в статье Использование виртуальных сетевых модулей на виртуальная сеть.
Рекомендации по развертыванию сетевого контроллера
- Не развертывайте роль сервера сетевого контроллера на физических узлах. Сетевой контроллер должен быть развернут на собственных выделенных виртуальных машинах.
- Сетевой контроллер можно развернуть как в доменных, так и в сторонних средах. В доменных средах сетевой контроллер проверяет подлинность пользователей и сетевых устройств с помощью Kerberos; В средах, отличных от домена, необходимо развернуть сертификаты для проверки подлинности.
- Для развертываний сетевых контроллеров крайне важно обеспечить высокий уровень доступности и возможность легко увеличивать или уменьшать масштаб в соответствии с потребностями центра обработки данных. Используйте по крайней мере три виртуальные машины, чтобы обеспечить высокий уровень доступности приложения сетевого контроллера.
- Для достижения высокого уровня доступности и масштабируемости сетевой контроллер использует Service Fabric. Service Fabric предоставляет платформу распределенных систем для создания масштабируемых, надежных и легко управляемых приложений. Дополнительные сведения о сетевом контроллере как приложении Service Fabric.
Дальнейшие действия
Дополнительные сведения см. также в разделе:
- Планирование развертывания сетевого контроллера
- Развертывание сетевого контроллера с помощью Windows PowerShell
- SDN в Azure Stack HCI и Windows Server
Контроллеры в Web API и обработка запросов
Контроллеры в Web API принимают запрос в виде объекта HttpRequestMessage , обрабатывают его с помощью одного из методов и посылают в ответ результат обработки в виде объекта HttpResponseMessage .
HttpRequestMessage с помощью своих свойств передает ряд данных о запросе:
- Content : возвращает объект HttpContent , который представляет тело запроса
- Headers : возвращает набор заголовков запроса в виде объектов HttpRequestHeader
- Method : тип запроса (Get/Post/Put/Delete)
- Properties : словарь, который содержит объекты, предоставляемые хостинговой средой
- RequestUri : запрошенный ресурс URL
- Version : используемая версия протокола HTTP
Например, получим все заголовки запроса:
public string Get() < string data=""; foreach(var o in Request.Headers) < string val = ""; foreach (string s in o.Value) < val += s + ";"; >data += o.Key + " : " + val; > return data; >
Объект запроса можно получить с помощью свойства Request
В то же время тем, кто привык к объектам контекста в ASP.NET MVC, могут не найти ряда полезных свойств. Например, в MVC через объекты контекста ( HttpContext.Current.Request.UserHostAddress ) можно получить адрес пользователя. В Web API мы так сделать не сможем, поэтому вполне можем использовать данный объект из mvc:
public string Get(int id)
Все контроллеры в Web API, в отличие от MVC, предоставляют реализацию интерфейса IHttpController :
public interface IHttpController < TaskExecuteAsync(HttpControllerContext controllerContext, CancellationToken cancellationToken); >
После обработки запроса системой маршрутизации его данные передаются объекту HttpControllerDispatcher . Этот объект уже и вызывает у контроллера метод ExecuteAsync() . В этот метод передается контекст контроллера HttpControllerContext, передающий информацию о запросе, а также объект CancellationToken
Web API имеет базовую встроенную реализацию данного интерфейса в виде класса ApiController , который, как правило, и используется для обработки запросов. Однако мы можем создать и свой контроллер. Например, создадим свой контроллер. Для этого добавим в папку Controllers следующий класс:
using System; using System.Net; using System.Net.Http; using System.Threading; using System.Threading.Tasks; using System.Web.Http.Controllers; using System.Web.Http.Routing; namespace WebApiApp.Controllers < public class ExchangeController : IHttpController < public TaskExecuteAsync(HttpControllerContext context, CancellationToken cancellationToken) < return Task.Run(() => < IHttpRouteData rd = context.RouteData; string output = "Неверный запрос"; if (rd.Values.ContainsKey("id")) < int sum; if (int.TryParse((string)rd.Values["id"], out sum) && sum>0) < double result = 1.3 * sum; output = String.Format("За евро вы получите долларов", sum, result); > > return context.Request.CreateResponse(HttpStatusCode.OK, output); >); > > >
В методе ExecuteAsync запускается новая задача с помощью вызова Task.Run() , в котором вычисляется количество долларов, полученных при обмене евро на доллары. Количество евро передается с помощью параметра в строке запроса, который мы получаем из коллекции context.RouteData . Поскольку по умолчанию в Web API определен один маршрут «api//», то мы можем использовать последний числовой параметр для передачи суммы евро.
Обратимся к контроллеру по запросу api/exchange/6 , и браузер нам выдаст результат:
"За 6 евро вы получите 7,8 долларов"
Как правило, в большинстве случаев вряд ли понадобится реализовывать интерфейс IHttpController, так как мы можем обойтись стандартным классом ApiController . Кроме того, Visual Studio имеет встроенную поддержку шаблонов для генерации контроллеров. Так, при добавлении нового контроллера нам будут доступны следующие опции:
Используя эти опции, можно автоматически создать контроллер со всеми нужными методами, использующими контекст данных для работы с бд.
Информация о контроллере
Используя свойство контроллера ControllerContext , представляющее объект HttpControllerContext, также содержит данные запроса, как и свойство RequestContext. Но кроме этого свойство ControllerContext также содержит и некоторые данные о контроллере.
HttpControllerContext определяет следующие свойства:
- Configuration : представляет объект HttpConfiguration , который содержит информацию о конфигурации приложения
- Controller : возвращает контроллер, обрабатывающий текущий запрос
- ControllerDescriptor : содержит объект HttpControllerDescriptor , который хранит информацию о контроллере
- Request : данное свойство хранит объект Http.HttpRequestMessage , предоставляющий информацию о запросе
- RequestContext : представляет объект HttpRequestContext , содержащий информацию о текущем запросе, специфичную для Web API
- RouteData : хранит данные маршрута
Используя контекст данных, можно получить всю необходимую информацию запросе:
public string Get(int id)
В данном случае получаем название контроллера, запрошенный путь, а также метод http.
HP предоставила новые подробности Endpoint Security Controller
Вместе с новыми ноутбуками этой весной HP раскрыла первые детали Endpoint Security Controller. Но до сих пор о данной функции защиты было известно мало. Она должна защищать систему от атак злоумышленников и каких-либо манипуляций на разных уровнях аппаратного и программного обеспечения.
Конечно, современное программное обеспечение разрабатывается таким образом, чтобы исключить какие-либо манипуляции. Intel и AMD давно предлагают функции защиты, являющиеся составной частью процессора или SoC. Иногда достаточно гарантировать целостность системы — с помощью сертификатов или межсетевых экранов на некоторых интерфейсах.
HP Endpoint Security Controller идет на шаг дальше. Он опирается на отдельный чип, припаянный на материнскую плату ноутбука. Архитектура чипа является собственной разработкой HP. Интересно, что HP использует данный чип уже многие годы, его можно обнаружить в том же EliteBook 800 G1 поколения 2013. Но HP пока не задействовала полный набор функций, что должно измениться в ближайшем будущем.
До сих пор HP задействовала Endpoint Security Controller только для технологии Sure Start, которая обеспечивает резервный BIOS на случай сбоя основного. Сегодня чип отслеживает Intel Management Engine, который стал целью многих атак. Данная функция усилена Sure Run и Sure Recover. Sure Run обеспечивает более эффективную изоляцию приложений, чтобы предотвратить атаки на них. А Sure Recover гарантирует простое и безопасное восстановление системы в корпоративном окружении.
Полный спектр функций Endpoint Security Controller сначала получат некоторые рабочие станции HP Elite, HP Pro и ZBook. В будущем HP планирует расширить набор функций.
Интересно отметить, что производители систем уже не всецело полагаются на функции защиты, предлагаемые Intel и AMD. По всей видимости, за последние месяцы AMD и Intel растеряли репутацию в данной сфере, и производители систем пытаются вновь завоевать доверие клиентов в бизнес-сегменте.
Параллели с Apple T2
Apple тоже довольно давно устанавливает фирменные чипы T1 и T2 в свои MacBook, iMac и Mac Mini. Чип T2 отвечает за шифрование и аутентификацию по отпечатку пальца Touch ID, но также содержит SSD-контроллер. Apple изолирует пользовательские данные от сторонних аппаратных компонентов, а также выполняет шифрование собственными средствами. Чип T2 также обеспечивает ускорение кодирования HEVC, в будущем он наверняка будет брать на себя еще больше функций.
Социальные сети
Теги
Источник и другие ссылки
комментарии (0)
Войдите, чтобы оставить комментарий
Возможно, вам будут интересны следующие статьи:
Тест и обзор: Lenovo LOQ 15IRH8 – хороший игровой.
Lenovo LOQ 15IRH8 – первый ноутбук производителя из новой линейки для массового рынка в нашей тестовой лаборатории. Новая серия была представлена в марте, Lenovo. [читать дальше]
Тест и обзор: ASUS ROG Strix G16 G614 – скоростной.
Будучи представителем серии Republic of Gamers, ROG Strix G16 относится к high-end моделям производителя, а значит, может похвастаться хорошим оснащением, в том числе скоростным. [читать дальше]
Тест и обзор: ASUS TUF Gaming F17 FX706HM – хороший.
Мы решили рассмотреть несколько моделей ноутбуков для школьников и студентов: они достаточно быстрые и прочные, чтобы справляться с учебой и рабочими сценариями. [читать дальше]
Тест и обзор: Acer Swift Go 14 – скромный, но.
По сравнению со многими ультрабуками на рынке линейка Swift Go от Acer выглядит довольно скромно. Но, несмотря на простой дизайн, в 14-дюймовом ультрабуке есть ряд. [читать дальше]
Тест и обзор: MSI Katana 15 B12VGK – быстрый, но.
Ноутбук MSI Katana 15 B12VGK обещает хорошее сочетание размеров и веса, а также производительности. При толщине корпуса 24,9 мм и весе 2,3 кг 15-дюймовый ноутбук оснащен. [читать дальше]
Тест и обзор: MSI Cyborg 15 A12VF – быстрый и.
15-дюймовый ноутбук MSI Cyborg 15 A12VF подходит для работы и учебы, также на нем можно вечером поиграть. Ноутбук выделяется компактными размерами и длительным временем. [читать дальше]
новости — категории
- Железо
- Процессоры
- Материнские платы
- Чипсеты
- Оперативная память
- Жёсткие диски и SSD
- Видеокарты
- Системы в сборке
- Ноутбуки и нетбуки
- Мониторы и проекторы
- Мультимедиа
- Корпуса
- Системы охлаждения
- Водяное охлаждение
- Сети
- Периферия
- Авто
Классы контроллеров
В этом разделе описаны все PHP классы, которые используются в WP API. Они делятся на два типа: Классы инфраструктуры и Классы контроллеров (маршрутов, конечных точек, ресурсов).
Оглавление:
- Общие сведения
- Классы инфраструктуры и Классы контроллеров
- Пример регистрации маршрута через Класс контроллера
- Принципы Классов контроллеров в WP API
- Заметка про наследование классов
Общие сведения
В WP API используется принцип Model-View-Controller — это стандартная модель в разработке приложений. Суть этой модели в том, что логика приложения разделена таким образом, что можно изменять одну его часть, так чтобы изменения не повлияли на другую его часть.
По такой схеме, логика кода WP-API разделена на независимые компоненты (классы):
- Класс получения запроса.
- Классы контроллеров (обработка запросы и создание ответа).
- Класс ответа на запрос (получает подготовленный контроллером ответ и формирует его в стандартный JSON вид, устанавливает заголовки ответа и код ответа).
Класс запроса и ответа — это Классы инфраструктуры WP API, с ними как правило работать не нужно. Мы, разработчики, почти всегда будем работать с Классом контроллера.
Задача Класса контроллера объединить отдельные части обработки запроса API в единый механизм. В них должны создаваться маршруты, они получают запросы обрабатывают их и генерируют ответы. Так же там описывается схема ресурса.
Концепция контроллера принята в рамках WP-API для того, чтобы иметь стандартный шаблон для Классов контроллера — классов представляющих ресурсы (конечные точки). Шаблоном класса контроллера является абстрактный класс WP_REST_Controller. Каждый класс контроллера должен иметь аналогичную схему методов, сделано так для того, чтобы все конечные точки имели одинаковые названия PHP методов.
Классы инфраструктуры и Классы контроллеров
Классы инфраструктуры дополняют классы контроллеров — они обрабатывают логику API, но не выполняют преобразований данных. Также и классы контроллеров (конечных точек) инкапсулируют логику необходимую для выполнения CRUD операций с ресурсами, но не связаны с логикой инфраструктуры. Это и есть упомянутая выше модель «Model-View-Controller».
К классам инфраструктуры относятся:
- WP_REST_Server — фундаментальный контроллер REST API, который обслуживает запрос. При любом запросе к API сначала вызывается WP_REST_Server и определяет, какой запрашивается маршрут, а затем передает коллбэк маршрута в объект WP_REST_Request . WP_REST_Server также выполняет проверку аутентификации и проверки валидации и доступа (validation и permissions).
- WP_REST_Request — этот объект содержит сведения о запросе, такие как заголовки запроса, параметры и метод, а также сам маршрут. Он также может проверять и очищать запрос (validation и sanitization).
- WP_REST_Response — отвечает за ответ на запрос. Устанавливает заголовки ответа, статус, тело ответа (JSON). Предоставляет вспомогательные методы add_link() (добавляет связанные с ответом ссылки) и query_navigation_headers() (данные навигации в заголовках).
К классам контроллеров относятся:
- WP_REST_Posts_Controller
- WP_REST_Users_Controller
- .
- Все классы REST API смотрите здесь.
Пример регистрации маршрута через Класс контроллера
Подробное описание этого примера смотрите в разделе Создание маршрутов.
// Запускаем наш контроллер и регистрируем маршруты add_action( 'rest_api_init', 'prefix_register_my_rest_routes' ); function prefix_register_my_rest_routes() < $controller = new My_REST_Posts_Controller(); $controller->register_routes(); > class My_REST_Posts_Controller extends WP_REST_Controller < function __construct()< $this->namespace = 'my-namespace/v1'; $this->rest_base = 'posts'; > function register_routes()< register_rest_route( $this->namespace, "/$this->rest_base", [ [ 'methods' => 'GET', 'callback' => [ $this, 'get_items' ], 'permission_callback' => [ $this, 'get_items_permissions_check' ], ], 'schema' => [ $this, 'get_item_schema' ], ] ); register_rest_route( $this->namespace, "/$this->rest_base/(?P[\w]+)", [ [ 'methods' => 'GET', 'callback' => [ $this, 'get_item' ], 'permission_callback' => [ $this, 'get_item_permissions_check' ], ], 'schema' => [ $this, 'get_item_schema' ], ] ); > function get_items_permissions_check( $request ) < if ( ! current_user_can( 'read' ) ) return new WP_Error( 'rest_forbidden', esc_html__( 'You cannot view the post resource.' ), [ 'status' =>$this->error_status_code() ] ); return true; > /** * Получает последние посты и отдает их в виде rest ответа. * * @param WP_REST_Request $request Текущий запрос. * * @return WP_Error|array */ function get_items( $request ) < $data = []; $posts = get_posts( [ 'post_per_page' =>5, ] ); if ( empty( $posts ) ) return $data; foreach( $posts as $post )< $response = $this->prepare_item_for_response( $post, $request ); $data[] = $this->prepare_response_for_collection( $response ); > return $data; > ## Проверка права доступа. function get_item_permissions_check( $request )< return $this->get_items_permissions_check( $request ); > /** * Получает отдельный ресурс. * * @param WP_REST_Request $request Текущий запрос. * * @return array */ function get_item( $request )< $id = (int) $request['id']; $post = get_post( $id ); if( ! $post ) return array(); return $this->prepare_item_for_response( $post, $request ); > /** * Собирает данные ресурса в соответствии со схемой ресурса. * * @param WP_Post $post Объект ресурса, из которого будут взяты оригинальные данные. * @param WP_REST_Request $request Текущий запрос. * * @return array */ function prepare_item_for_response( $post, $request )< $post_data = []; $schema = $this->get_item_schema(); // We are also renaming the fields to more understandable names. if ( isset( $schema['properties']['id'] ) ) $post_data['id'] = (int) $post->ID; if ( isset( $schema['properties']['content'] ) ) $post_data['content'] = apply_filters( 'the_content', $post->post_content, $post ); return $post_data; > /** * Подготавливает ответ отдельного ресурса для добавления его в коллекцию ресурсов. * * @param WP_REST_Response $response Response object. * * @return array|mixed Response data, ready for insertion into collection data. */ function prepare_response_for_collection( $response ) < if ( ! ( $response instanceof WP_REST_Response ) )< return $response; >$data = (array) $response->get_data(); $server = rest_get_server(); if ( method_exists( $server, 'get_compact_response_links' ) ) < $links = call_user_func( [ $server, 'get_compact_response_links' ], $response ); >else < $links = call_user_func( [ $server, 'get_response_links' ], $response ); >if ( ! empty( $links ) ) < $data['_links'] = $links; >return $data; > ## Схема ресурса. function get_item_schema() < $schema = [ // показывает какую версию схемы мы используем - это draft 4 '$schema' =>'http://json-schema.org/draft-04/schema#', // определяет ресурс который описывает схема 'title' => 'vehicle', 'type' => 'object', // в JSON схеме нужно указывать свойства в атрибуете 'properties'. 'properties' => [ 'id' => [ 'description' => 'Unique identifier for the object.', 'type' => 'integer', 'context' => [ 'view', 'edit', 'embed' ], 'readonly' => true, ], 'vin' => [ 'description' => 'VIN code of vehicle.', 'type' => 'string', ], // TODO добавить поля // [] ], ]; return $schema; > ## Устанавливает HTTP статус код для авторизации. function error_status_code() < return is_user_logged_in() ? 403 : 401; >>
Принципы Классов контроллеров в WP API
Классы контроллеров решают две проблемы при разработке эндпоинтов:
- Отсутствие пространств имен — WordPress не использует пространства имён PHP (для поддержки PHP 5.2). Оборачивание группы PHP функций которые описывают конечную точку в класс, позволяет избежать конфликтов с названиями функций. Например, мы назвали функцию get_items() и другой разработчик сделал тоже самое, в результате сайт перестанет работать из-за фатальной ошибки PHP.
- Согласование структур — Один раз разобравшись со структурой класса контроллера, разработчики смогут быстро понимать структуру класса контроллера, которую писал другой человек.
Для классов контроллеров разработчиками создан специальный шаблон: абстрактный класс WP_REST_Controller. На его основе рекомендуется создавать свои контроллеры маршрутов. Так например, все классы конечных точек WP расширяют WP_REST_Controller , например:
class WP_REST_Posts_Controller extends WP_REST_Controller < // . >
Методы класса-шаблона WP_REST_Controller :
Метод Описание метода register_routes() вызывается при первом создания экземпляра класса и регистрирует маршруты. get_items() получает коллекцию ресустов (постов, рубрик и т.д.). get_item() получает отдельный ресурс (пост, рубрику и т.д.). Если ресурса не существует, будет возвращен HTTP статус 404. Если нет права просматривать ресурс, то статус будет 403. create_item() создает новый ресурс. Если создание прошло успешно, то WP_REST_Response вернет HTTP статус 201 и ссылку на созданный ресурс. Если создание не удалось, то будет возвращен соответствующий код ошибки в HTTP заголовке. update_item() обновляет существующий ресурс. delete_item() удаляет существующий ресурс. Если удаление не удалось, то будет возвращен соответствующий код ошибки в HTTP заголовке. get_items_permissions_check() перед вызовом коллбэк функции проверяет есть ли право у текущего запроса получать коллекцию ресурсов. get_item_permissions_check() перед вызовом коллбэк функции проверяет есть ли право у текущего запроса получать отдельный ресурс. create_item_permissions_check() перед вызовом коллбэк функции проверяет есть ли право у текущего запроса создавать ресурс. update_item_permissions_check() перед вызовом коллбэк функции проверяет есть ли право у текущего запроса обновлять ресурс. delete_item_permissions_check() перед вызовом коллбэк функции проверяет есть ли право у текущего запроса удалять ресурс. prepare_item_for_response() изменяет данные ресурса, чтобы они подходили под схему ответа. prepare_response_for_collection() prepare_item_for_response() возвращает объект WP_REST_Response . Это вспомогательная функция, которая собирает такие ответы в общую коллекцию ресурсов и возвращает эту коллекцию в качестве ответа. filter_response_by_context() фильтрует данные ресурса в соответствии с указанным параметром context . get_item_schema() получает объект схемы ресурса. Заметка про наследование классов
Не следует злоупотреблять наследованием классов. Например: если мы написали класс контроллера для эндпоинта записей (пример выше) и хотим также поддерживать произвольные типы записей, то не следует расширять свой класс My_REST_Posts_Controller следующим образом:
class My_CPT_REST_Controller extends My_REST_Posts_Controller
Вместо этого нужно либо создать отдельный класс контроллера, либо заставить My_REST_Posts_Controller обрабатывать все доступные типы записей. Дело в том, что родительский класс (тот который наследуется) может измениться, а наши подклассы зависят от него, в результате получаем головную боль. Поэтому, если нужна общая структура для классов, необходимо создать свой базовый класс контроллера в виде интерфейса или абстрактного класса, а затем использовать его как основу для подклассов. Такой подход абстрактного класса используется во многих конечных точках REST API WordPress. Например, классы WP_REST_Posts_Controller, WP_REST_Terms_Controller и т.д. расширяют абстрактный класс WP_REST_Controller.