Я ищу советы и опыт, относящиеся к лучшему способу поведения / концепций REST-ify, которые не являются "обычно сохраняющимися", - другими словами, преобразующие поведение с поведением или побочные эффекты.
Во-первых, позвольте мне сказать, что я знаю, что нет полного теста на полноту REST - и на самом деле мне все равно.Я считаю, что понятие REST CRUD-over-the-Web очень интуитивно понятно и хорошо работает с большинством данных, к которым я предоставляю доступ.В то же время, я не беспокоюсь о том, чтобы отклониться от чьей-либо библии о том, как идеально ОТДЫХАТЬ что-то.Я нахожусь в поиске лучшего компромисса между практическим и REST-интуитивным для случаев, которые не подходят так хорошо.Ясно, что последовательность является главной целью, но интуитивность помогает обеспечить это.
Учитывая это, позвольте мне углубиться в детали того, что мне нужно.
Поскольку REST по своей природе ориентирован на ресурсы, легко моделировать вещи, которые обычно сохраняются - что менее ясно, так этокак моделировать поведение / концепции, которые обычно не сохраняются, особенно те, которые имеют побочные эффекты или являются чисто трансформационными.
Например, возьмите вопрос на stackoverflow.com.Он может быть создан, обновлен, прочитан и удален.Каждый может относиться к этому, и все это имеет смысл в REST.
Но теперь рассмотрим что-то вроде перевода - например, я хочу создать REST API для своего сервиса, который переводит английское предложение на испанский.
Существует как минимум два способа решения сценария перевода.Я мог бы:
Рассматривать вызов перевода как создание «экземпляра перевода» (который не сохраняется, но может быть), в этом случае POST /Перевод (т.е. создание) на самом деле имеет большой смысл.Это особенно верно, если служба перевода требует, чтобы URL чего-либо переводился (так как содержимое этого URL может изменяться со временем).
Рассматривайте перевод как действительно запрос большого словаря известных ответов, в этом случае более подходящим может быть GET / Перевод (то есть чтение).Это особенно заманчиво, если для перевода требуется только текст предложения.Никто не ожидал бы, что перевод статического предложения изменится со временем.Вы также можете утверждать, что он может быть кэшируемым, к чему может привести GET.
Эта та же самая дилемма может возникнуть для других действий, которые в основном имеют побочные эффекты (например, отправка SMS илиэлектронной почтой) и реже ассоциируются с постоянством данных.
До сих пор мой подход заключался в том, чтобы по существу "заказать" - уточнить эти случаи, то есть смотреть на все так, как если бы кто-то размещал заказ,В более общем смысле, я думаю, что это просто преобразование глаголов (переводить) в существительные (порядок перевода), что, по-видимому, является одним из способов REST-поиска таких вещей.
Может ли кто-нибудь поделиться лучшим, более интуитивным способомподойти к моделированию действий / поведения, которые обычно не считаются постоянными?