Меньше всего нагрузки даст php файл, который в начале server.php зареквайрен, но возникает проблема с тем, что это исполняемый код, соответственно, нужно очень внимательно относиться к изменению этого файла из админки на предмет всяких инъекций. Валидировать всё по максимуму, запретить произвольные строки, добавлять экранирование и вот это всё.
Access-Control-Allow-Origin specifies either a single origin which tells browsers to allow that origin to access the resource; or else — for requests without credentials — the "*" wildcard tells browsers to allow any origin to access the resource.
По русски - нельзя вайлкардить origin для запросов с авторизацией. Весьма вероятно это в консоли девтулзов разъяснено.
Ну а про постман выше написали.
Вот это делает ровно что нужно, обходи свой массив в цикле и в условие обновления ставь свой артикул. Подходит, если нету хуков. Если есть - то надо получать модель, если нашлась - обновлять поля, сохранять, если не нашлась - то переходить к следующей итерации.
ну значит нужно отдавать не id а uuid v4 (это пример, можно любой другой рандом, чем больше, тем лучше), а id хранить в таблице на стороне сервера, причем можно еще делать отдельную привязку к ip / useragent или времени последнего запроса (например ip (или диапазон) может измениться в течении суток-двух, у useragent версия увеличиться на 1, иначе сессия с таким id невалидна)
вместо попытки выбросить отсутствующий элемент проще создать массив с последовательными значениями и выбирать из него случайные элементы в диапазоне от 0 до length-1 на каждой итерации, удаляя выбранный.
Значение будет установлено до конца выполнения скрипта (а не функции), так что нужно вернуть настройки самому. Этому может помочь то, что ini_set возвращает старое значение настройки (или false).
А вообще это все написано в документации