2015-10-20 1 views
0

Я изучаю, как разработать API RESTful, и я столкнулся с затруднительным положением.Как создать RESTful API, который запрашивает информацию о глаголе (например, потенциальный запрос POST)?

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

POST /flooblinate 
{"intensity": 50, "colorful": true, "blargs": [{"norg": 43}]} 

POST /flooblinate 
{"intensity": 100, "colorful": false, "blargs": []} 

Произнесите один стоит 500, а второй один стоит 740.

Я хочу создать метод, который сообщит мне, что стоимость размещения действия будет быть. Поскольку я ничего не создаю и не обновляю, кажется, что GET является наиболее подходящим глаголом. Однако a request body with GET should not have any meaning. Это означает, что я должен поместить данные в строку запроса, скажем, по URL, кодирующего тело запроса передается в POST:

GET /flooblinate/getCost?body=%7B%22intensity%22%3A+50%2C+%22colorful%22%3A+true%2C+%22blargs%22%3A+%5B%7B%22norg%22%3A+43%7D%5D%7D 

Это кажется меньше, чем идеал, так как это два формата данных для того же вещь. Но следующее:

POST /flooblinate/getCost 
{"intensity": 50, "colorful": true, "blargs": [{"norg": 43}]} 

Это также, кажется, меньше, чем идеал, так как это злоупотребление глагол POST для запроса информации, вместо того, чтобы создать или обновить что-нибудь.

Какой правильный выбор сделать здесь? Есть ли какая-то третья альтернатива? Есть ли способ переосмыслить этот проект в принципе, который избавит вас от необходимости сделать этот выбор?

ответ

0

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

POST /flooblinate?dryRun=true 
{"intensity": 50, "colorful": true, "blargs": [{"norg": 43}]} 

Возвращает:

{"cost": 500, /* whatever else */ 

А затем размещение с dryRun=false фактически совершает действие.

1

Лично я не для добавления dryRyn флагов. Я стараюсь избегать булевых флагов вообще, если они действительно не требуются.

Я две идеи, чтобы покрыть этот сценарий:

  1. Один должен представить состояние на сайте бэкэнд, например, STARTED, FINISHED. Когда данное действие ресурса представлено, оно имеет состояние STARTED и вычисляет стоимость, которую кулачка просматривает с помощью метода GET. Такой ресурс может быть изменен с помощью методов PUT и PATCH и представляется, когда данный метод изменяет свое состояние на FINISHED. Ресурсы, которые не изменяли свое состояние для заданного количества времени, удаляются, их состояние изменяется на другое значение терминала.
  2. Вторая идея - представить новую конечную точку, называемую, например, /calculations. Если вам нужно рассчитать стоимость данного действия, вы просто отправляете ту же полезную нагрузку (через POST) в эту конечную точку и взамен указывается стоимость. Затем отправка ресурсов может храниться на сервере для определенного TTL или храниться навсегда.

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

+0

# 1 звучит как самый подход RESTful. Было бы больше работать на заднем плане, чтобы поддержать это, но это может быть самое приятное в целом. О # 2, не злоупотреблять ли использование POST только для запроса данных? Как и в, не должно быть GET? POST is * "Метод POST используется, чтобы запросить, чтобы исходный сервер принял объект, заключенный в запросе, в качестве нового подчиненного ресурса, идентифицированного Request-URI в строке запроса. * *, А GET - *. Метод GET означает получение любой информации (в форме объекта), идентифицируемой Request-URI. "* (Из RFC2616, раздел 9) – Claudiu

+0

Также почему вы пытаетесь избежать логических флагов вообще? – Claudiu

+0

Когда дело доходит до булевых флагов, я некоторое время назад поддерживал [anti-if-campaign] (http://antiifcampaign.com/), и я сильно ассоциировал с ним случайный булевский флаг. Итак, поскольку я связываю логические с операторами if, я стараюсь избегать их, если это невозможно. – Opal