Как сохранить RESTful со сложным API

#ruby-on-rails #rest

#ruby-on-rails #rest

Вопрос:

Мои настройки: Rails 2.3.10, Ruby 1.8.7

Мне нужно реализовать API, который по сути является GET, но в зависимости от даты может включать также действия DELETE и POST. Позвольте мне объяснить, что для определенного дня API необходимо добавить 10 элементов в одну таблицу, случайно выбранную из другой таблицы, но это делается только один раз в день. Если добавленные элементы относятся к предыдущему дню, то API необходимо удалить эти элементы и случайным образом добавить 10 новых. Если в один и тот же день выполняется несколько вызовов API, то это просто GET после первоначального создания. Надеюсь, в этом есть какой-то смысл.

Как бы я реализовал это как RESTful API, если это вообще возможно.

Ответ №1:

Как насчет?

 GET /Items
  

Если наступил следующий день, сгенерируйте 10 новых элементов, прежде чем возвращать их. Если следующий день не наступил, верните те же 10 элементов, которые вы вернули ранее. Нет причин, по которым сервер не может обновлять элементы на основе GET. Клиент не запрашивает обновление, поэтому запрос по-прежнему считается безопасным.

Комментарии:

1. Согласен, похоже, у клиента нет никаких причин рассматривать этот запрос как что-либо иное, кроме GET . Нет необходимости раскрывать реализацию, которую сервер использует для генерации этого набора данных как часть абстракции, предоставляемой клиентам.

Ответ №2:

Не уверен, что я правильно вас понимаю, но, просто взглянув на это, все, что я могу подумать, это следующее: Какая ужасная вещь — выполнять add, который в зависимости от того, что он добавлен, выполняет delete. Без неуважения, но серьезно. Или, может быть, это так, как вы это описываете.

В любом случае, если вы хотите иметь RESTful API, тогда вам нужно обращаться с GET и PUT по-разному.

Я не думаю, что у вас есть четкое представление о том, как должен быть выполнен ваш API (или ваша система, если на то пошло).) Мое предложение состояло бы в том, чтобы повторно смоделировать это следующим образом:

Определите URI для вашего ресурса, скажем, / random-items

  • a GET /random-items возвращает вам от 0 до 10 элементов, находящихся в данный момент в системе.

  • PUT/random-items с пустым телом выполняется следующее:

    • удалите все случайные элементы, добавленные вчера или ранее
    • добавьте столько случайных элементов, сколько необходимо для завершения 10
  • вызов DELETE /random-items ) должен возвращать 405 Method Not Allowed код ошибки http.

  • вызов POST /random-items` должен добавлять не более 10 элементов, удаляя по мере необходимости.

  • /random-items/x является допустимым URI, если x является одним из элементов, находящихся в данный момент в / random-items.

    • GET К нему должно возвращаться представление для него или 404, если оно не существует
    • DELETE К нему удаляет его из-под /random-items или 404, если он не существует
    • PUT Для него следует изменить свое значение, если это имеет смысл (или вернуть 405 )
    • POST К нему должно возвращаться 405 всегда

Это должно дать вам что-то вроде скелета RESTful API.

Однако, если вы настаиваете или вам нужно перегрузить GET, чтобы он выполнял добавления и удаления за сценой, тогда вы делаете его не RESTful.

Это само по себе неплохо, если у вас есть законная потребность в этом (поскольку ни одна архитектурная парадигма не является универсально применимой). Но вам нужно понимать, что означает RESTful и когда / почему / как его прервать.

Комментарии:

1. Да, я знаю, это звучит ужасно, поэтому я пытаюсь выяснить, как лучше всего с этим справиться. Я понимаю REST, и то, что вы предлагаете, является RESTful-иш, как вы упомянули. Возможно, это тот случай, когда я нарушаю принцип REST, потому что сложная логика полностью находится на серверной части без необходимости во внешнем интерфейсе выполнять эти отдельные вызовы, что и является моей дилеммой с самого начала. Все, о чем заботится API, — это предоставить мне 10 элементов на сегодня, но логика требует, чтобы эти 10 элементов менялись ежедневно. Я полагаю, я мог бы реализовать ежедневное задание CRON в серверной части для заполнения и изменения 10 элементов.

2. Нет, просто перегрузите GET и PUT, как упоминалось здесь (при этом DELETE и POST возвращают значение 405), а PUT выполняет удаления и обновления (оба требуют логики арифметики даты) за кулисами. Затем задание cron может получить доступ к ресурсу / обновить его с помощью curl -T .