REST API (OData): как за один ХТТП-запрос обновить объект БД, не зная его ГУИД?
Обновление объекта ПУТ-/ПАТЧ-запросом, зная его ГУИД, проверил - работает:
А как за один ХТТП-запрос обновить объект, используя поиск по значению реквизита объекта?
Сделал ПАТЧ-запрос для объекта с поиском не по ГУИДу, добавив в "заголовок" (а вернее в URL) параметры $filter и $top.
По итогу ГЕТ-запрос с такими параметрами возвращает мне несколько или один элемент <entry> (объект, удовлетворяющий отбору).
А вот в ПАТЧ-запросе вываливается ошибка с кодом 19: "Использованный HTTP метод запрещен в данном контексте"
Пока делаю вывод, что за один ХТТП-запрос нельзя обновить объект БД, не зная его ГУИДа: нужно сначала ГЕТ-запросом получить ГУИД объекта, а затем уже изменять его ПАТЧ-/ПУТ-запросом.
Если кто-то достиг результата за один ХТТП-запрос - поделитесь.
А как за один ХТТП-запрос обновить объект, используя поиск по значению реквизита объекта?
Сделал ПАТЧ-запрос для объекта с поиском не по ГУИДу, добавив в "заголовок" (а вернее в URL) параметры $filter и $top.
По итогу ГЕТ-запрос с такими параметрами возвращает мне несколько или один элемент <entry> (объект, удовлетворяющий отбору).
А вот в ПАТЧ-запросе вываливается ошибка с кодом 19: "Использованный HTTP метод запрещен в данном контексте"
Пока делаю вывод, что за один ХТТП-запрос нельзя обновить объект БД, не зная его ГУИДа: нужно сначала ГЕТ-запросом получить ГУИД объекта, а затем уже изменять его ПАТЧ-/ПУТ-запросом.
Если кто-то достиг результата за один ХТТП-запрос - поделитесь.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) на сколько мне известно, PATCH используется для частичной модификации существующего объекта, на который указывает некий Request-URI. Если он, типа, ни на что не указывает, то может быть создан новый документ - это приведено в спецификации HTTP 1.1 тут:
Фактически, на сколько я могу понять из приведенного по сцылке документа, PATCH частично модифицирует очень конкретный документ, а не их группу.
Фактически, на сколько я могу понять из приведенного по сцылке документа, PATCH частично модифицирует очень конкретный документ, а не их группу.
(2)
PATCH частично модифицирует очень конкретный документ, а не их группу
Ну, Я тоже хочу модифицировать очень конкретный объект (пусть будет документ). ГЕТ-запрос, ищущий по значению реквизита ($filter), возвращает мне один конкретный объект БД - проверено.
(1) это невозможно в принципе. Иначе будет нарушен стандарт OData.
А в чем смысл одновременного получения и обновления?
Operations allow the execution of custom logic on parts of a data model. Functions do not allow side effects and are composable. Actions allow side effects and are not composable. Actions and functions are global to the service and MAY be used as members of entities and collections of entities.
А в чем смысл одновременного получения и обновления?
(6)
в чем смысл одновременного получения и обновления?
Ну, не одновременного, а последовательного, но в рамках одного ХТТП-запроса. Просто мне кажется, что один ХТТП-запрос лучше двух: как в плане нагрузки на инфобазу и веб-сервер, так и в плане удобства для источника ХТТП-запроса, ведь выполняется конретная "точечная" задача (обновления первого попавшегося объекта БД, найденного по реквизитам поиска) и разбивать ее на две (сначала поиск и получение ключа, затем обновление по ключу) просто кажется излишним...
Кратко: POST — создание, PUT — обновление
Авторитетного источника применительно к REST не будет, так как REST, строго говоря, не определяет ни POST, ни PUT. REST просто допускает использование HTTP. Следовательно наиболее авторитетный источник по поводу POST/PUT — это спецификация HTTP 1.1:
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.
The PUT method requests that the enclosed entity be stored under the supplied Request-URI.
То есть POST используется для создания подчиненной сущности, а PUT для сохранения сущности.
POST в случае успеха всегда должен возвращать статус 201 (Created) и Location на новый ресурс.
PUT же может возвращать как 201 (если ресурс не найден), так и 204 (No Content) — если ресурс обновлялся.
Авторитетного источника применительно к REST не будет, так как REST, строго говоря, не определяет ни POST, ни PUT. REST просто допускает использование HTTP. Следовательно наиболее авторитетный источник по поводу POST/PUT — это спецификация HTTP 1.1:
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.
The PUT method requests that the enclosed entity be stored under the supplied Request-URI.
То есть POST используется для создания подчиненной сущности, а PUT для сохранения сущности.
POST в случае успеха всегда должен возвращать статус 201 (Created) и Location на новый ресурс.
PUT же может возвращать как 201 (если ресурс не найден), так и 204 (No Content) — если ресурс обновлялся.
(15)The PUT method requests that the enclosed entity be stored under the supplied Request-URI.
То есть POST используется для создания подчиненной сущности, а PUT для сохранения сущности.
POST в случае успеха всегда должен возвращать статус 201 (Created) и Location на новый ресурс.
PUT же может возвращать как 201 (если ресурс не найден), так и 204 (No Content) — если ресурс обновлялся.
То есть POST используется для создания подчиненной сущности, а PUT для сохранения сущности.
POST в случае успеха всегда должен возвращать статус 201 (Created) и Location на новый ресурс.
PUT же может возвращать как 201 (если ресурс не найден), так и 204 (No Content) — если ресурс обновлялся.
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот