Вурдалак
Продвинутый новичок
Ну, не совсем. @grigori верно отметил, что REST в большей степени используется не на «полную», а лишь в лучшем случае на уровне level 2, поэтому мы видим тонну говно-API с CRUD-методами, ограниченными базовыми HTTP-глаголами. HATEOAS — интересная тема, правда даже в таком случае мне бы хотелось более явного RPC API а-ля GraphQL, потому что по моему опыту делать ресурсы а-ля /user/42/banUser получается геморройнее, чем если бы я просто отправлял команду BanUser с payload на определённый endpoint. Сюда же можно отнести чейнинг методов, с более-менее классическим RPC это делается проще. Я может ничего нового и не узнаю, но это может быть полезно другим, кто до сих пор верит в то, что POST /user/42 {"ban": true} — это true REST.
Есть ещё одна причина некоторой нелюбви к REST, но это больше опять-таки относится к недо-REST: вот эти споры на уровне «POST или PUT», «DELETE или POST» в случае неоднозначных команд. С обычными бизнес-глаголами о таком задумываться не будешь. Есть такие методы, которые могут просто что-то менять в сущности, но при стечении обстоятельств (например, expires < текущего времени) они удаляют сущность, и это вводит в ступор новичков и не только: разве POST должен удалять ресурс? Также никогда нельзя быть уверенным, что один и тот же глагол не придётся разбить на 2: сейчас мы удаляем только одним способом и пишем DELETE /users/42, а через год мы сможем насчитать их несколько + нужен некий payload (чего DELETE не поддерживает). Получается, нам по умолчанию всегда нужно писать POST /resource/action. А тогда спрашивается зачем нужен REST?
Ещё мне не очень нравится идея использовать HTTP-глагол в качестве бизнес-глагола (как с BAN): семантически, это именно HTTP-глагол. Если я хочу «отправить посылку» (post package), то столкнусь с тем, что вообще говоря, я понимаю под этим одно, а выглядит как самый обычный POST-метод. Упомянутый DELETE тоже имеет ограничения, хотя я, возможно, использую его в каком-то контексте как бизнес-глагол и хочу payload.
Ну и про PATCH хотелось послушать, раз уж @grigori его упомянул. Как по мне, так это тот же самый треш, что и POST/PUT/DELETE, который мешает явно выделить бизнес-действие.
Есть ещё одна причина некоторой нелюбви к REST, но это больше опять-таки относится к недо-REST: вот эти споры на уровне «POST или PUT», «DELETE или POST» в случае неоднозначных команд. С обычными бизнес-глаголами о таком задумываться не будешь. Есть такие методы, которые могут просто что-то менять в сущности, но при стечении обстоятельств (например, expires < текущего времени) они удаляют сущность, и это вводит в ступор новичков и не только: разве POST должен удалять ресурс? Также никогда нельзя быть уверенным, что один и тот же глагол не придётся разбить на 2: сейчас мы удаляем только одним способом и пишем DELETE /users/42, а через год мы сможем насчитать их несколько + нужен некий payload (чего DELETE не поддерживает). Получается, нам по умолчанию всегда нужно писать POST /resource/action. А тогда спрашивается зачем нужен REST?
Ещё мне не очень нравится идея использовать HTTP-глагол в качестве бизнес-глагола (как с BAN): семантически, это именно HTTP-глагол. Если я хочу «отправить посылку» (post package), то столкнусь с тем, что вообще говоря, я понимаю под этим одно, а выглядит как самый обычный POST-метод. Упомянутый DELETE тоже имеет ограничения, хотя я, возможно, использую его в каком-то контексте как бизнес-глагол и хочу payload.
Ну и про PATCH хотелось послушать, раз уж @grigori его упомянул. Как по мне, так это тот же самый треш, что и POST/PUT/DELETE, который мешает явно выделить бизнес-действие.
Последнее редактирование:
Проблема с REST не в том, что идею искривили, а в том, что люди его не могут. Например, в корпорации, в которой принят хороший внутренний стандарт, разработчики предпочитают в документацию по API добавить раздел с описанием нарушений стандарта. А сделать RPC, и не морочить голову с REST - боятся.