WordPress как на ладони
rgbcode is looking for WordPress developers. Очень Удобный и Быстрый Хостинг для сайтов на WordPress. Пользуюсь сам и вам рекомендую!

Типы параметров REST. Проверка и очистка

С версии 5.2 WordPress в ядро встроена проверка и очистка параметров, передаваемых в маршруты REST API (валидатор параметров определенных типов). Такая проверка основана на спецификации JSON Schema Version 4. В этой статье будут рассмотрены основы JSON схемы, которые используются в WordPress для проверки и очистки (validate и sanitize).

Читайте связанное:

Описанные ниже типы параметров указываются при регистрации маршрута и его эндпоинтов в функции register_rest_route().

Рассмотрим пример, в котором видно как и где указываются параметры эндпоинта о которых ниже пойдет речь:

$endpoints = [
	[
		'methods'             => 'GET',
		'callback'            => [ $this, 'get_items' ],
		'permission_callback' => [ $this, 'get_items_permissions_check' ],
		'args'                => [
			// string
			'context' => [
				'description'       => __( 'Scope under which the request is made; determines fields present in response.' ),
				'type'              => 'string',
				'sanitize_callback' => 'sanitize_key',
				'validate_callback' => 'rest_validate_request_arg',
			],
			// integer
			'per_page' => [
				'description'       => __( 'Maximum number of items to be returned in result set.' ),
				'type'              => 'integer',
				'default'           => 10,
				'minimum'           => 1,
				'maximum'           => 100,
				'sanitize_callback' => 'absint',
				'validate_callback' => 'rest_validate_request_arg',
			],
			// array
			'author' => [
				'description' => __( 'Limit result set to posts assigned to specific authors.' ),
				'type'        => 'array',
				'items'       => [
					'type' => 'integer',
				],
				'default'     => [],
			],
			// string enum
			'order' => [
				'description' => __( 'Order sort attribute ascending or descending.' ),
				'type'        => 'string',
				'default'     => 'desc',
				'enum'        => [ 'asc', 'desc' ],
			],
			// string pattern
			'slug'   => [
				'type'        => 'string',
				'required'    => true,
				'description' => __( 'WordPress.org plugin directory slug.' ),
				'pattern'     => '[\w\-]+',
			],

		],
	]
];

register_rest_route( 'namespace', '/rest_base', $endpoints );

type

В JSON схеме доступны следующие семь примитивных типов:

  • string — строковое значение.
  • null — значение null.
  • number — Любое число. Эквивалент float в PHP.
  • integer — Целое число. float не допускается.
  • boolean — значение true/false.
  • array — Список значений. Эквивалент массива в JavaScript. В PHP соответствует массиву с числами в ключах или массиву без указанных ключей.
  • object — Пары ключ => значение. Эквивалент объекта в JavaScript. В PHP соответствует ассоциативному массиву (массиву с ключами).

Примитивный тип указывается в type элементе массива. Например:

array(
	'type' => 'string',
);

JSON схема позволяет указать сразу несколько типов:

array(
	'type' => [ 'boolean', 'string' ],
);

Преобразование типов

REST API WordPress принимает данные в GET или POST запросе, поэтому данные нужно преобразовать. Например некоторые строковые значения нужно превратить в их реальные типы.

  • string — этот тип должен пройти проверку is_string().
  • null — значение должно быть реальным null. Это означает, что отправка null значения в URL-адресе или в виде закодированного в форме URL тела сообщения невозможна, необходимо использовать тело запроса JSON.
  • number — число или строка, которая пройдет проверку is_numeric(). Значение будет преобразовано во (float).
  • integer — Целые числа или строки без дробной части. Значение будет преобразовано во (int).
  • boolean — Логические true/false. Числа или строки 0, 1, '0', '1', 'false', 'true'. 0 это false. 1 это true.
  • array — Индексный массив соответствующий wp_is_numeric_array() или строка. Если передана строка, то значения разделенные запятыми станут значениями элементов массива. Если запятых в строке нет, то значение станет первым элементом массива. Например: 'red, yellow' превратится в array( 'red', 'yellow' ), а 'blue' станет array( 'blue' ).
  • object — Массив, объект stdClass, объект применяемый JsonSerializable или пустая строка. Значения будут преобразованы в PHP массив.

При использовании нескольких типов, типы будут обрабатываться в указанном порядке. Это может повлиять на результат очистки. Например для 'type' => [ 'boolean', 'string' ] отправленное значение '1' превратиться в логическое true. Однако, если поменять порядок, то значение будет строка '1'.

Спецификация JSON схемы позволяет определять схемы без поля type. Но в WordPress этот параметр должен быть указан, иначе вы получите заметку _doing_it_wrong().

string

Указывает на то что в значении запроса должна быть строка. Дополнительными параметрами ниже можно определить какая именно строка должна передаваться в значении параметра.

minLength / maxLength

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

Например для следующей схемы ab, abc, abcd пройдут проверку, а a и abcde нет.

array(
	'type' => 'string',
	'minLength' => 2,
	'maxLength' => 4,
);

format

Если указать этот аргумент, то значения параметра переданного в REST будут проверятся на соответствие указанному формату.

Возможные варианты параметра:

Пример использования параметра format:

array(
	'type'   => 'string',
	'format' => 'date-time',
);

Важно: значение параметра должно соответствовать указанному формату всегда, поэтому оно не может быть пустой строкой. Если нужна возможность указать пустую строку, то нужно добавить тип null.

Например, следующая схема разрешит указать IP (127.0.0.1) или не указывать значение параметра:

array(
	'type'   => [ 'string', 'null' ],
	'format' => 'ip',
);

Код из ядра, который показывает как конкретно работает этот параметр:

// This behavior matches rest_validate_value_from_schema().
if ( isset( $args['format'] )
	&& ( ! isset( $args['type'] ) || 'string' === $args['type'] || ! in_array( $args['type'], $allowed_types, true ) )
) {
	switch ( $args['format'] ) {
		case 'hex-color':
			return (string) sanitize_hex_color( $value );

		case 'date-time':
			return sanitize_text_field( $value );

		case 'email':
			// sanitize_email() validates, which would be unexpected.
			return sanitize_text_field( $value );

		case 'uri':
			return esc_url_raw( $value );

		case 'ip':
			return sanitize_text_field( $value );

		case 'uuid':
			return sanitize_text_field( $value );
	}
}

Обратите внимание, что format обрабатывается не обязательно только тогда когда type = string. format будет применяться если:

  • type = string.
  • type отличается от стандартного примитивного типа.
  • type не указан (но в WP это запрещено).

pattern

Используется для проверки соответствия значения строкового параметра указанному регулярному выражению.

Например, для следующей схемы, #123 подходит, а #abc нет:

array(
	'type'    => 'string',
	'pattern' => '#[0-9]+',
);

Модификаторы регулярных выражений не поддерживаются, т.е. нельзя указать /i, чтобы не зависеть от регистра.

RFC схемы JSON рекомендует ограничиться следующими функциями регулярных выражений, чтобы схема была совместима с как можно большим количеством различных языков программирования:

  • Разрешены отдельные символы Юникод соответствующие JSON спецификации [RFC4627].
  • Простая группа и диапазон символов: [abc] и [a-z].
  • Простая группа и диапазон исключающих символов: [^abc], [^a-z].
  • Просты квантификаторы: * (ноль или более), + (один или более), ? (один или ничего), и их «ленивые» версии: +?, *?, ??.
  • Квантификаторы диапазона: {x} (x раз), {x,y} (от x до y раз), {x,} (x и более раз), и их «ленивые» версии.
  • Анкоры начала и конца строки: ^, $.
  • Простыe группы (...) и чередование |.

Шаблон должен быть совместим с диалектом регулярных выражений ECMA 262.

null

Значение должно быть реальным null. Это означает, что отправка null значения в URL-адресе или в виде закодированного в форме URL тела сообщения невозможна, необходимо использовать тело запроса JSON.

boolean

Логические true/false. Можно запросе можно указать числа или строки:

  • true — 1, '1', 'true'.
  • false — 0, '0', 'false'.

Подробнее о том, как обрабатывается переданное значение смотрите в коде функции: rest_sanitize_boolean().

number / integer

Числа имеют тип number (любое число, может быть дробным) или integer (только целые числа):

if ( 'integer' === $args['type'] ) {
	return (int) $value;
}

if ( 'number' === $args['type'] ) {
	return (float) $value;
}

Для чисел также есть дополнительные параметры проверки.

minimum / maximum

Ограничивает диапазон допустимых чисел (включая сами числа). Например, 2 подойдет под схему ниже, а 0 и 4 - нет:

array(
	'type' => 'integer',
	'minimum' => 1,
	'maximum' => 3,
);

exclusiveMinimum / exclusiveMaximum

Это дополнительные параметры для minimum / maximum, которые отключают «включительную» проверку. Т.е. значение НЕ может равняться определенному минимуму или максимуму а должно быть больше или меньше, но не равно.

Например, в следующем случае приемлемым значением будет только 2:

array(
	'type'             => 'integer',
	'minimum'          => 1,
	'exclusiveMinimum' => true,
	'maximum'          => 3,
	'exclusiveMaximum' => true,
);

multipleOf

Утверждает кратность числа, т.е. полученное значение должно нацело делиться на указанное в этом параметре число.

Например, следующая схема будет принимать только четные целые числа:

array(
	'type'       => 'integer',
	'multipleOf' => 2,
);

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

array(
	'type'       => 'number',
	'minimum'    => 0,
	'maximum'    => 100,
	'multipleOf' => 0.1,
);

array

Указывает что должен быть передан массив. Смотрите: rest_sanitize_array().

items

Устанавливает формат каждого элемента в массиве. Для этого нужно использовать параметр items, в котором нужно указать JSON схему каждого элемента массива.

Например, следующая схема требует массив IP-адресов:

array(
	'type'  => 'array',
	'items' => array(
		'type'   => 'string',
		'format' => 'ip',
	),
);

Для такой схемы эти данные пройдут проверку:

[ "127.0.0.1", "255.255.255.255" ]

А эти нет:

[ "127.0.0.1", 5 ]

Схема items может быть любой, в том числе и схемой вложенного массива:

array(
	'type'  => 'array',
	'items' => array(
		'type'  => 'array',
		'items' => array(
			'type'   => 'string',
			'format' => 'hex-color',
		),
	),
);

Для такой схемы эти данные пройдут проверку:

[
  [ "#ff6d69", "#fecc50" ],
  [ "#0be7fb" ]
]

А эти не пройдут:

[
  [ "#ff6d69", "#fecc50" ],
  "george"
]

minItems / maxItems

Используется для ограничения минимального и максимального количества элементов массива (включительно).

Например, следующая схема пропустит данные [ 'a' ] и [ 'a', 'b' ], но не пропустит
[] и [ 'a', 'b', 'c' ]:

array(
	'type'     => 'array',
	'minItems' => 1,
	'maxItems' => 2,
	'items'    => array(
		'type' => 'string',
	),
);

uniqueItems

Используется когда нужно, чтобы значения массива были уникальны. Смотрите: rest_validate_array_contains_unique_items().

Например, следующая схема посчитает правильными данные [ 'a', 'b' ], и не правильными [ 'a', 'a' ]:

array(
	'type'        => 'array',
	'uniqueItems' => true,
	'items'       => array(
		'type' => 'string',
	),
);
Важно знать об уникальности значений.
  • Значения разных типов рассматриваются как уникальные. Например, '1', 1 и 1.0 — это разные значения.

  • При сравнении массивов, порядок элементов имеет значение. Например у такого массива значения будут считаться уникальными:

    [
      [ "a", "b" ],
      [ "b", "a" ]
    ]
  • При сравнении объектов, порядок определения свойств НЕ имеет значения. Например у такого массив объекты будут считаться одинаковыми:

    [
      {
    	"a": 1,
    	"b": 2
      },
      {
    	"b": 2,
    	"a": 1
      }
    ]
  • Уникальность проверяется рекурсивно для значений массивов в обеих функциях: rest_validate_value_from_schema() и rest_sanitize_value_from_schema(). Нужно это для того чтобы не было моментов, когда items могут быть уникальными до очистки и одинаковыми после.

    Возьмем для примера такую схему:

    array(
    	'type' => 'array',
    	'uniqueItems' => true,
    	'items' => array(
    		'type' => 'string',
    		'format' => 'uri',
    	),
    );

    Такой запрос прошёл бы проверку потому что строки разные:

    [ "https://site.com/hello world", "https://site.com/hello%20world" ]

    Однако после обработки функцией esc_url_raw() строки станут одинаковые.

    В этом случае rest_sanitize_value_from_schema() вернула бы ошибку. Поэтому вам всегда следует проверить и очищать параметры.

object

Этот тип требует, чтобы принимаемые данные были объектом. Также нужно указать формат каждого свойства объекта в параметре properties.

См. rest_sanitize_object().

properties

Обязательные свойства объекта. Для каждого свойства указывается своя схема.

Например, следующая схема требует объект, где свойство name является строкой, а color шестнадцатеричным цветом.

array(
	'type'       => 'object',
	'properties' => array(
		'name'  => array(
			'type' => 'string',
		),
		'color' => array(
			'type'   => 'string',
			'format' => 'hex-color',
		),
	),
);

Такие данные пройдут проверку:

{
  "name": "Primary",
  "color": "#ff6d69"
}

А такие не пройдет:

{
  "name": "Primary",
  "color": "orange"
}
Обязательные свойства

По умолчанию все свойства, перечисленные для объекта, являются необязательными, поэтому, если какого-то свойства будет не хватать в объекте, проверка все равно будет пройдена.

Есть два способа сделать свойство обязательным.

Способ 1: добавить поле required для каждого свойства.

Это синтаксис 3 версии схемы JSON:

array(
	'type'       => 'object',
	'properties' => array(
		'name'  => array(
			'type'     => 'string',
			'required' => true,
		),
		'color' => array(
			'type'     => 'string',
			'format'   => 'hex-color',
			'required' => true,
		),
	),
);

Способ 2: добавить поле required в общий массив где перечистить обязательные свойства.

Это синтаксис 4 версии схемы JSON:

register_post_meta( 'post', 'fixed_in', array(
	'type'         => 'object',
	'show_in_rest' => array(
		'single' => true,
		'schema' => array(
			'required'   => array( 'revision', 'version' ),
			'type'       => 'object',
			'properties' => array(
				'revision' => array(
					'type' => 'integer',
				),
				'version'  => array(
					'type' => 'string',
				),
			),
		),
	),
) );

Теперь следующий запрос не пройдет проверку:

{
	"title": "Check required properties",
	"content": "We should check that required properties are provided",
	"meta": {
		"fixed_in": {
			"revision": 47089
		}
	}
}

Если мета-поле fixed_in вообще не указать, то никакой ошибки не возникнет. Объект, определяющий список обязательных свойств, не определяет сам объект обязательным. Просто если объект указан, то обязательные свойства также должны быть указаны.

Синтаксис 4 версии не поддерживается для схем эндпоинта верхнего уровня в WP_REST_Controller::get_item_schema().

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

array(
	'$schema'    => 'http://json-schema.org/draft-04/schema#',
	'title'      => 'my-endpoint',
	'type'       => 'object',
	'required'   => array( 'title', 'content' ),
	'properties' => array(
		'title'   => array(
			'type' => 'string',
		),
		'content' => array(
			'type' => 'string',
		),
	),
);

additionalProperties

Определяет может ли объект содержать дополнительные свойства не указанные в схеме.

По умолчанию схема JSON позволяет указывать свойства, которые не указаны в схеме.

Таким образом, чтобы следующее не прошло проверку, нужно указать параметр additionalProperties = false, т.е. неописанные в схеме (дополнительные) свойства запрещены.

array(
	'type'                 => 'object',
	'additionalProperties' => false,
	'properties'           => array(
		'name'  => array(
			'type' => 'string',
		),
		'color' => array(
			'type'   => 'string',
			'format' => 'hex-color',
		),
	),
);

Ключевое слово additionalProperties само может быть использовано как схема свойств объекта. Так неизвестные свойства должны будут пройти указанную проверку.

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

array(
	'type'                 => 'object',
	'properties'           => array(),
	'additionalProperties' => array(
		'type'       => 'object',
		'properties' => array(
			'name'  => array(
				'type'     => 'string',
				'required' => true,
			),
			'color' => array(
				'type'     => 'string',
				'format'   => 'hex-color',
				'required' => true,
			),
		),
	),
);

Теперь следующие данные пройдут проверку:

{
  "primary": {
	"name": "Primary",
	"color": "#ff6d69"
  },
  "secondary": {
	"name": "Secondary",
	"color": "#fecc50"
  }
}

А вот эти не пройдут:

{
  "primary": {
	"name": "Primary",
	"color": "#ff6d69"
  },
  "secondary": "#fecc50"
}

patternProperties

Ключевое слово patternProperties аналогично ключевому слову additionalProperties, но позволяет утверждать, что свойство соответствует шаблону регулярных выражений. Ключевое слово - это объект, где каждое свойство является шаблоном регулярных выражений, а его значение - JSON схемой, используемой для проверки свойств, соответствующих этому шаблону.

Например, эта схема требует, чтобы каждое значение было шестнадцатеричным цветом, а свойство должно содержать только символы “слова”.

array(
  'type'                 => 'object',
  'patternProperties'    => array(
	'^\\w+$' => array(
	  'type'   => 'string',
	  'format' => 'hex-color',
	),
  ),
  'additionalProperties' => false,
);

В результате это пройдет проверку:

{
  "primary": "#ff6d69",
  "secondary": "#fecc50"
}

А это не пройдет:

{
  "primary": "blue",
  "$secondary": "#fecc50"
}

При проверке схемы patternProperties, если свойство не соответствует ни одному из шаблонов, это свойство будет разрешено и его содержимое не будет никак проверяться. Если такое поведение не подходит, то вам нужно запретить неизвестные (дополнительные) свойства с помощью параметра additionalProperties.

minProperties / maxProperties

Используется для ограничения минимального и максимального количества свойств объекта (включительно). Это аналоги свойств minItems и maxItems у массива.

Это может быть полезно при описании схемы где разрешаются неизвестные свойства объекта, но их должно быть ограниченное кол-во. Например:

array(
  'type'                 => 'object',
  'additionalProperties' => array(
	'type'   => 'string',
	'format' => 'hex-color',
  ),
  'minProperties'        => 1,
  'maxProperties'        => 2,
);

Эти данные пройдут проверку:

{
  "primary": "#52accc",
  "secondary": "#096484"
}

А вот эти нет:

{
  "primary": "#52accc",
  "secondary": "#096484",
  "tertiary": "#07526c"
}

enum

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

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

enum проверяется только при проверке значения (validate не sanitize) в функции rest_validate_value_from_schema().

Пример использования параметра:

array(
	'description' => __( 'Order sort attribute ascending or descending.' ),
	'type'        => 'string',
	'default'     => 'asc',
	'enum'        => array(
		'asc',
		'desc',
	),
);

Код из ядра, показывает как именно делается проверка:

if ( ! in_array( $value, $args['enum'], true ) ) {
	return new WP_Error( 'rest_invalid_param', sprintf( __( '%1$s is not one of %2$s.' ), $param, implode( ', ', $args['enum'] ) ) );
}

oneOf / anyOf

Совпадение с одной или любой из описанных схем. Смотрите: rest_find_any_matching_schema(), rest_find_one_matching_schema().

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

  • anyOf разрешает, чтобы значение соответствовало одной из указанных схем или нескольким схемам.
  • oneOf требует, чтобы значение подходило только под одну схему (не под две и более).

Например, эта схема позволяет отправлять массив "операций" в конечную точку. Каждая операция может быть либо "crop", либо "rotation".

array(
	'type'  => 'array',
	'items' => array(
		'oneOf' => array(
			array(
				'title'      => 'Crop',
				'type'       => 'object',
				'properties' => array(
					'operation' => array(
						'type' => 'string',
						'enum' => array(
							'crop',
						),
					),
					'x'         => array(
						'type' => 'integer',
					),
					'y'         => array(
						'type' => 'integer',
					),
				),
			),
			array(
				'title'      => 'Rotation',
				'type'       => 'object',
				'properties' => array(
					'operation' => array(
						'type' => 'string',
						'enum' => array(
							'rotate',
						),
					),
					'degrees'   => array(
						'type'    => 'integer',
						'minimum' => 0,
						'maximum' => 360,
					),
				),
			),
		),
	),
);

REST API пройдет циклом по каждой схеме, указанной в массиве oneOf и проверит соответствие. Если совпадает только одна схема, то проверка будет успешной. Если подходят несколько схем, проверка провалится. Если схемы не совпадают, то валидатор попытается найти наиболее близкую совпадающую схему и вернет соответствующее сообщение об ошибке.

operations[0] is not a valid Rotation. Reason: operations[0][degrees] must be between 0 (inclusive) and 360 (inclusive)

Чтобы генерировать понятные сообщения об ошибках, рекомендуется присвоить каждой схеме в массиве oneOf или anyOf свойство title.

Как работает проверка и очистка

В REST API определены две базовые функции для работы с JSON схемой:

Обе функции принимают значение которое нужно проверить/очистить, схему параметра и название параметра (название будет выводится в сообщении при ошибке).

Использовать эти функции нужно в строгом порядке: сначала проверять значение (validate) и только потом его очищать (sanitize). Если не использовать какую-либо из проверок, то данные эндпоинта могут оказаться недостаточно защищены.

Регистрация параметров эндпоинта и проверка/очистка

Рассмотрим на примере как это происходит. Допустим мы регистрируем роуты в контроллере следующим образом:

class WP_REST_Terms_Controller extends WP_REST_Controller {

	...

	public function register_routes() {

		register_rest_route( 'my/v1', '/myelem',
			array(
				array(
					'methods'             => 'GET',
					'callback'            => array( $this, 'get_items' ),
					'permission_callback' => array( $this, 'get_items_permissions_check' ),
					'args'                => $this->get_collection_params(),
				),
				array(
					'methods'             => 'POST, PUT',
					'callback'            => array( $this, 'create_item' ),
					'permission_callback' => array( $this, 'create_item_permissions_check' ),
					'args'                => $this->get_endpoint_args_for_item_schema( 'POST, PUT' ),
				),
				'schema' => array( $this, 'get_public_item_schema' ),
			)
		);

		...
	}

	...
}
Если параметры эндпоинта полностью соответствую схеме ресурса

То для регистрации возможных параметров эндпоинта можно использовать метод WP_REST_Controller::get_endpoint_args_for_item_schema(). В этом случае клбэки проверки/валидации будут добавлены автоматически.

Как это происходит:

public function get_endpoint_args_for_item_schema( $method = WP_REST_Server::CREATABLE ) {
	return rest_get_endpoint_args_for_schema( $this->get_item_schema(), $method );
}

В функцию rest_get_endpoint_args_for_schema() передается схема $this->get_item_schema() и на её основе собирается список доступных параметров, в данные которых добавляются колбэки проверки и очистки:

$endpoint_args[ $field_id ] = array(
	'validate_callback' => 'rest_validate_request_arg',
	'sanitize_callback' => 'rest_sanitize_request_arg',
);
Если параметры эндпоинта не соответствую схеме ресурса

То колбэки очистки и валидации можно указать вручную или не указывать вообще.

Если колбэк очистки не указан в параметре sanitize_callback отдельного параметра запроса, то его автоматически добавит метод WP_REST_Request::sanitize_params(), который вызывается из WP_REST_Server::dispatch() при обработке данных запроса.

Например:

$query_params['author_email'] = array(
	'type'        => 'string',
	'format'      => 'email',
	'description' => 'Parameter Description.',
);

// тоже самое что
$query_params['author_email'] = array(
	'type'        => 'string',
	'format'      => 'email',
	'description' => 'Parameter Description.',
	'sanitize_callback' => 'rest_parse_request_arg',
);

Код из ядра, который показывает как добавляется колбэк очистки:

// If the arg has a type but no sanitize_callback attribute, default to rest_parse_request_arg.
if ( ! array_key_exists( 'sanitize_callback', $param_args ) && ! empty( $param_args['type'] ) ) {
	$param_args['sanitize_callback'] = 'rest_parse_request_arg';
}

Код rest_parse_request_arg():

function rest_parse_request_arg( $value, $request, $param ) {
	$is_valid = rest_validate_request_arg( $value, $request, $param );

	if ( is_wp_error( $is_valid ) ) {
		return $is_valid;
	}

	$value = rest_sanitize_request_arg( $value, $request, $param );

	return $value;
}

Обратите внимание что, перед очисткой значения делается и проверка. Поэтому нет необходимости указывать аргумент validate_callback когда для очистки используется функция rest_parse_request_arg().

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

$query_params['page'] = array(
	'description'       => __( 'Current page of the collection.' ),
	'type'              => 'integer',
	'default'           => 1,
	'sanitize_callback' => 'absint',
	'validate_callback' => 'rest_validate_request_arg',
	'minimum'           => 1,
),
1 комментарий
    Войти