Какого типа рест-запрос для сложного комплексного расчёта?

Сложная UI-форма, которая используется только для расчётов и никуда не сохраняется. Т.е. пользователь открыл окно/страницу расчётов, выбрал кучу разных параметров, добавил десяток позиций, для каждой так же указал параметры и какие-то подчинённые коллекции. Сохранять это не нужно, это просто заготовка. Далее, пользователь нажал "выполнить расчёт", по всем параметрам выполнился расчёт, пользователь получил данные по каждой позиции и сводные данные. Закрыл окно/страницу без сохранения.

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

Вопрос : какого типа будет этот запрос с точки зрения хотя бы намёка на классчиеский REST с его ресусами и активным использованием HTTP-глаголов?
* мне эта идеология очень не нравится, ибо нормальную предметную область в неё в принципе не впихнуть, разве что простейший CRUD, но web-фронтэндеры, почему-то, яростно агитируют исключительно за него.

С одной стороны - надо передать на сервер увесистый многоуровневый JSON со всеми теми данными, что навыбирал пользователь. Т.е. разумно было бы использовать POST. Но POST - это ведь запрос на создание/добавление нового ресурса. А тут ничего не создаётся и не добавляется, и ID не генерится. Т.е. более логично использовать GET? Однако, отправлять http-тело в GET-запросе не самая популярная практика. А значит придётся весь этот увесистый JSON упаковывать в query-string. Да, туда можно очень много записать, но насколько корректно передавать там несколько [десятков] килобайт?

0

kotelok, я за POST.

1

OwenGlendower,
Вообще, если подумать, то, наверно, можно и более чисто выкрутиться, т.е.:
[POST] /api/calculations {JSON-body with GUID} => возвращает "ок, расчёт выполнен и отправлен в хранилище".

После чего фронт делает:
[GET] /api/calculations/{guid} => возвращает рассчёт, выполненный и сохранённый предыдущим вызовом.

Но это два HTTP-запроса получается. Хотя, если коннект не обрывается и клиент повторно не проходит все шаги https-подключения, то накладные расходы будут не такие уж и большие.

0

kotelok, это имеет смысл делать если расчет занимает продолжительное время. Также можно наворотить вариант с 1) POST создание расчета, возвращает id 2) несколько PUT запросов добавляющих/обновляющих части расчета и наконец 3) GET для получения результата. Вопрос только зачем если можно обойтись одним POSTом. При условии что можно.

1

kotelok, ...
я тоже не понимаю этой ярости в сохранениее идеологии со стороны идеологов ... ведь даже классическая корзина в онлайн-магазине - это не только создание нового ресурса (заказа пользователя), но и просто фильтр отбора в первую очередь (т.е. Get) ... Почему нельзя отбирать по POST (я так и делаю, грешен) - не понимаю ...

1

carrotik,
Там не только проблема "получение данных через POST", там ещё и все эти упоротые преподвыверты в попытках вкорячить полноценную доменную логику в, по сути, простейший CRUD-"репозиторий" (ну, не совсем, но близко по смыслу).

Т.е. даже минимальный CRUD для обычного UI-приложения в REST не впихнуть без боли, т.к. у тебя есть:
[GET] /api/items/?filter=<**> => коллекция полных айтемов.
[GET] /api/items/{id}/ => полный айтем по ID.
[POST] /api/items/ {DTO-body} => создание
[PUT] /api/items/{id}/ {DTO-body} => обновление
[DEL] /api/items/{id}/ => удаление

И это бесполезно, т.к. для типового UI с гридом, редактированием через форму, кастомными действиями и частичными выборками, дополнительно нужно:
1. GET-запрос по ID, который возвращает DTO только с частью полей айтема.
2. GET-запрос с фильтром (оциональным), который возвращает коллекцию DTO с частью полей.
3. POST-запрос не на создание или обновление, а на:
3.1. Смену разных статусов сущности с одного на другой.
3.2. Выполнение какого-то кастомного экшена над сущностью с доп-параметрами указанными пользователем и вообще без сохранения/получения чего-нибудь из хранилища.

И все эти действия, что очевидно, относятся именно к '/api/items', но адепты упорно предлагают наваливать кучи вырожденных урлов типа:
[GET] /api/itemsShort/?filter=<**> => коллекция урезанных DTO
[GET] /api/itemsShort/{id}/ => урезанный DTO по ID.
[GET] /api/itemsWithoutRemark/?filter=<**> => коллекция DTO с айтемами без комментариев.
[GET] /api/itemsWithoutRemark/{id}/ => айтем без комментария по ID.

А для кастомных действий создавать неочевидные подколлекции со странной логикой:
[PUT] /api/items/{id}/someStatuses/0/ {body with new status}
* где '0' - константа, т.к. у документа может быть только один такой статус.

Потому как вот так вот нельзя, ибо глаголы в урле это не канонично:
[PUT] /api/items/{id}/changeSomeStatus {body with new status}

0

Сообщение от kotelok Но POST - это ведь запрос на создание/добавление нового ресурса.

Не только:

9.5 POST 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. POST is designed to allow a uniform method to cover the following functions: - Annotation of existing resources; - Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; - Providing a block of data, such as the result of submitting a form, to a data-handling process; - Extending a database through an append operation. The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database. The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

2