Добрый день!
Начал изучать Web API. Практически все статьи оперируют самым минимумом: put,post,get,delete. И если как писать функции с разным количеством параметров еще более или менее понятно (например, получить список модель-объектов, получить конкретную модель-объект по id). Но возьмем пример чуть сложнее. Есть массив объект-моделей представляющих собой строку. Нужно реализовать:
— для массива
-- добавить новый объект в конец
-- добавить новый объект в начало
-- добавить новый объект в указанное место (по индексу массива)
— для конкретного объекта
-- добавить строку в начало
-- добавить строку в конец
-- добавить строку в конкретное место (по величине сдвига от начала)

И как это правильно (идеологически выдержано) все это реализовать? Потому что в голову приходит только создание для каждого метода своего url пути. Навроде:
/objects/createinstart
/objects/createinend
/objects/createinindex

Но я не уверен, что такой подход правильный.

Здравствуйте, CyberRussia, Вы писали:

CR>Добрый день!
CR>Начал изучать Web API. Практически все статьи оперируют самым минимумом: put,post,get,delete. И если как писать функции с разным количеством параметров еще более или менее понятно (например, получить список модель-объектов, получить конкретную модель-объект по id). Но возьмем пример чуть сложнее. Есть массив объект-моделей представляющих собой строку. Нужно реализовать:
CR>- для массива
CR>-- добавить новый объект в конец
CR>-- добавить новый объект в начало
CR>-- добавить новый объект в указанное место (по индексу массива)
CR>- для конкретного объекта
CR>-- добавить строку в начало
CR>-- добавить строку в конец
CR>-- добавить строку в конкретное место (по величине сдвига от начала)

CR>И как это правильно (идеологически выдержано) все это реализовать? Потому что в голову приходит только создание для каждого метода своего url пути. Навроде:
CR>/objects/createinstart
CR>/objects/createinend
CR>/objects/createinindex

CR>Но я не уверен, что такой подход правильный.

А я с этим не парюсь, если честно, и называю методы контролеров так как мне удобно, а не как "идеологически верно". Если эта идеология неудобна, то зачем она нужна? А по вопросу, то можно и один метод использовать с указанием способа вставки.

Здравствуйте, Qulac, Вы писали:
Q>А я с этим не парюсь, если честно, и называю методы контролеров так как мне удобно, а не как "идеологически верно". Если эта идеология неудобна, то зачем она нужна? А по вопросу, то можно и один метод использовать с указанием способа вставки.
Вопрос скорее не в способе именования. А в подходе в целом. Мне в голову пришло несколько методов. Вы говорите, что можно один, но с параметром типа вставки. Кто-то может еще что-то назовет. Вопрос какой из вариантов выбрать идеологически. Что более правильно, или более принято в разработке на сегодняшний день?

Здравствуйте, CyberRussia, Вы писали:

CR>Здравствуйте, Qulac, Вы писали:
Q>>А я с этим не парюсь, если честно, и называю методы контролеров так как мне удобно, а не как "идеологически верно". Если эта идеология неудобна, то зачем она нужна? А по вопросу, то можно и один метод использовать с указанием способа вставки.
CR>Вопрос скорее не в способе именования. А в подходе в целом. Мне в голову пришло несколько методов. Вы говорите, что можно один, но с параметром типа вставки. Кто-то может еще что-то назовет. Вопрос какой из вариантов выбрать идеологически. Что более правильно, или более принято в разработке на сегодняшний день?

Больше принято один метод на одно действие. Я бы так и сделал.

Здравствуйте, CyberRussia, Вы писали:

Стараются сделать как можно проще.

Например свести к наименьшему числу методов (в разумных пределах), например update, где передается массив ссылок/id на объекты в нужном порядке.

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

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

В любом подходе будут свои ограничения / соответствие или несоответствие требованиям.

Здравствуйте, CyberRussia, Вы писали:

CR>Но я не уверен, что такой подход правильный.
Обычно рекомендация что в урле у тебя используются сущности, а не действия. И самое главное — учти, что Web API разрабатывается с т.з. распределённой системы.
Т.е. делаешь ты "/objects/createinindex" — и связь оборвалась — как клиент узнает — сработал ли вызов или нет? Должен он повторить операцию или нет? Думай об идемпотентных операциях.
Что происходит при коллизиях: два клиента добавляют что-то в позицию X — кто-то из них должен обломаться? Или оба отработать, один перезапишет другого? Или оба вставятся один за другим? Можешь посмотреть в сторону Operational Transformations
Например, самый простой вариант если следовать соглашениям на именование REST, то скорее всего будет как-то так:
POST /objects?position=X — если X=0 — значит в начало, X=n — на n-ную позицию (существущие эл-ты сдвигаются к концу). Параметр отсутствует — в конец.
Либо можно указывать позицию относительно существующего объекта с данным id: POST /objects?afterId=abc POST /objects?beforeId=xyz.

Здравствуйте, CyberRussia, Вы писали:

CR>И как это правильно (идеологически выдержано) все это реализовать? Потому что в голову приходит только создание для каждого метода своего url пути. Навроде:
CR>/objects/createinstart
CR>/objects/createinend
CR>/objects/createinindex


--POST
/objects/firstItem
/objects/lastItem
/objects/item/7