На самом деле действие «Поразить карлика ядовитой стрелой» вполне себе описывается в терминах REST. Допустим, есть некий ресурс баталии /battle/12345, тогда для этого ресурса может быть описан запрос по методу POST, в который передаётся объект «удар», который описывает, кто чем и кого бьёт. POST-запрос создаёт в системе новый объект, который фактом своего существования меняет состояния других объектов: того, кто бьёт (уменьшает запас боеприпасов) и того, кого бьют (уменьшает здоровье).
На мой взгляд, любую задачу можно описать в любом API. Это всё война остроконечников и тупоконечников.
Да, неплохой пример. Но лично я пока слабо представляю как переписал бы API рабочего проекта, придерживаясь REST... Слишком много объектов получается, навскидку. И выгоды неясны. С другой стороны, я эту тему как раз и привнес, чтобы взглянуть с разных углов на проектирование серверных API )))
Конечно, переписывать ничего не надо, особенно, если всё уже работает :) И естественно, что для каждой задачи лучше подходит какой-то определённый API. Это как корпускулярно-волновой дуализм — можно до потери пульса спорить, что такое свет, но для одной задачи удобнее считать его материей, а для другой — волной.
Если бы вы позвали в гости представителя какого-нибудь кровавого энтерпрайза, он бы на корню разбил все преимущества REST перед RPC, потому что и недостатков в определённых случаях у него тоже хоть отбавляй :)
В общем, согласен. Можно, конечно, сделать URI типа /battle/12345/hit (тут и понятность, и роутинг) и слать запросы на него, но в данном случае RPC выглядел бы органичнее.
Вообще, мы верим нашему гостю по дефолту ))) Можно погуглить на предмет записи выступления, может быть появилось видео (я не нашел). Если обнаружишь это дело, поделись ссылкой!