Прочитал статью про REST (https://habrahabr.ru/post/265845/) и во многом согласился с автором.
Однако комменты к ней в основном отрицательные. Интересно узнать Ваше мнение.
REST предполагает проприетарный протокол обмена информацией (в основном JSON). При этом также предполагается лихорадочное "кодирование" служебной информации в URL с помощью GET, POST и т.д. (причем это никак не стандартизовано и никак самим HTTP не предусматривалось). Вопрос номер 1: Почему не поместить ее в JSON сообщение? Все равно никакого стандарта нет, так REST это скорее паттерн нежели технология.  
Можно согласиться с тем, что некоторые приложения по природе диктуют stateless подход, так как навигационные пути в них имеют динамическую природу. Вопрос номер 2: Кто мешает писать stateless серверную часть без всякого выделывания с REST?
Единый интерфейс совместно с stateless природой в некоторых вышеупомянутых приложениях, с динамической природой навигационных путей) может дать отличный результат. Вопрос номер 3: Но почему это считается присущим исключительно REST?
То есть основная масса поборников ведет прямо таки религиозную борьбу за флаг REST "наводя тень на плетень". Ладно это сделал Фильдинг - он ведь писал диссертацию (сам писал - понимаю, как хочется придумать в ней что-то эдакое). REST как паттерн нужен в небольшом количестве приложений, но и в этом случае нет никакой нужды уродовать смысл HTTP запросов. Причем многие из тех, кто искренне считают, что используют REST, нарушая его принципы, обманывая самих себя, так у них получается вовсе не REST. Но они то свято верят в свою правоту. То есть появление идеологии REST в конечном итоге привело не к новой технологии, а к большому самообману некоторых IT профессионалов. В конечном итоге стоило бы просто состряпать что-то типа SOAP на JSON, а не на XML. А остальные принципы оформить в паттерн.
В таком контексте было бы меньше ругани и больше понимания сути. А?

что статья сумбурная, что сообщение здесь.  но тут лучше, конечно, каждое предложение просто сказка.
фразой "проприетарный протокол обмена информацией (в основном JSON)" вы что хотели сказать?
"кодирование" служебной информации в URL с помощью GET, POST и т.д. (причем это никак не стандартизовано и никак самим HTTP не предусматривалось) — что тут сказано?
и да, главное, причем тут java?

REST это просто идея как писать сервисы. Именно идея, никакого стандарта нет, жестких правил и критериев нет. Вот SOAP это стандарт, а REST - нет.

Мне в REST нравится то, что они пытаются по максимуму использовать возможности HTTP, а не городить свой огород поверх HTTP, вводя всё то же самое, но своё.

1. Насчет сумбура это скорее к форме, чем к содержанию - нет смысла отвечать.

2. А вот фраза "они пытаются по максимуму использовать возможности HTTP, а не городить свой огород поверх HTTP, вводя всё то же самое, но своё" - это как раз то, о чем был вопрос. REST предполагает, что для каждого запроса используется свой адрес, а значит по сути отдельный обработчик запроса.
Однако возникает задача выподнять разные действия одним обработчиком и тогда привлекаются GET, POST и т.д. Но количество желаемых действий больше, чем типов HTTP запросов (они создавались не для этого). Тогда начинается добавление в адрес дополнительных компонентов а типы HTTP запросов трактуются как ни будь особо. Действие может оказаться и вовсе вызовом какого-то метода, что закодировать через адрес или заголовок совсем не просто. То есть, когда служебная информация запроса перемещается в структуру адресов и заголовков HTTP, которая для этого не предназначена, начинается чехарда с договоренностями, специальными соглашениями и т.п. Вот и спрашивается: Зачем помещать это с вывертами в HTTP, когда можно отправить в теле HTTP (XML или JSON). Адрес определяет то, каков будет обработчик, а описание действий и специфическую информацию вполне можно разместить в теле POST HTTP запроса - все равно ведь семантика и синтаксис каждого REST сервиса произвольны. (Об этом, кстати и была статья.) Более того, такую структуру служебной информации легче сделать стнадартной, хотя бы в рамках одной организации. Конечно, иногда закрадывается крамольное подозрение, что структура HTTP протокола не совсем удовлетворяет сегодняшнему состоянию работы приложений в среде Интернет. Тем более кажется не совсем правильным изворачиваться пропихивая без особой нужды в застывшую структуру типов HTTP запросов и заголовков служебную информацию сервиса - все равно, как заливать новое вино в старые меха.

4. К Java EE этот вопрос по-моему имеет прямое отношение - разве нет?

5. Вопрос показался актуальным после прочтения старой статьи М.Фаулера о микросервисах. Система построенная на микросервисах предполагает использование относительно свободного протокола вызовов (скорее всего внутри HTTP) и предположительно REST. Однако, представьте себе тот REST, который мы знаем внутри сотен микросервисов одной организации и какое усилие понадоюится, чтобы закодировать все разнообразие микросевисов HTTP запросами и заголовками.

Можно сказать, что идея микросервисов модна и поэтому именно из-за моды менеджеры некоторых организаций эту архитектуру "пропихивают" насильственно (но мода имеет свойство проходить). Однако, на самом деле последовательное проведение в жизнь парадигмы слабого связывания естественно ведет к использованию микросервисов. Однако отсутствие всяких стандартов в части интерфейса взаимодействия сервисов поначалу кажущееся благом, в конечном итоге приведет к тому, что некоторые системы, построенные на этой архитектуре начнут "сыпаться" именно из-за отсутствия такового стандарта. Вспомните причину появления контроллеров и введения паттерна MVC в web приложениях - причина та же: преимущество обернувшееся кучей проблем (хорошее описание можно найти в старой, но не утратившей актуальности, книге Брюса Тейта "Горький вкус Java"). Ну, конечно же у меня на заднем плане всегда имеет место мысль - а может я чего недопонимаю в архитектурном паттерне REST. Потому то и спрашиваю, а не из желания "профигурировать", в чем меня косвенно упрекает zera. 

Разные URL не предполагают, что используются разные обработчики. Даже простой HTTP servlet можно замаппить на группу адресов. А продвинутые фреймворки вообще сами разберут URL на части и выделят нужные параметры.




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

вопрос именно по содержанию, причем не статьи, а в первую очередь вашего сообщения.  
что за "проприетарный протокол обмена информацией (в основном JSON)", это кроме как вранье и рассматривать странно.  или вы про конкретный формат конкретной реализации?
вторая фраза, что я процитировал тоже похожа на вранье, методы вполне описаны в rfc.  если для вас в ресте http методы используются не для того, для чего их придумывали, то, может быть, вы рест неправильно используете?  
в статье, к тому же, прицепили зачем-то браузеры. да и то, отправка delete запроса постом с примечанием была актуальна, мне кажется, лет пять назад, если не десять.  но тут уж если у вас клиент в браузере, то становится становится странной претензия к тому, что рест привязан к http.  
да и вообще итоговый json-pure это тот же рест и есть. 

Сколь я понимаю идею мистера Фильдинга, она состоит в упрощении создания и работы сервиса. Конечно, можно иметь один обработчик на группу URL. На этом форуме как-то был вопрос:"У меня в REST на один адрес приходят три разных XML сообщения. Как узнать какое сообщение пришло не разбирая его полностью?". Автору был предложен один из вариантов решений с сообщением, что у него вовсе не REST. Конечно же один обработчик может принимать много адресов - предельный случай это контроллер в web слое, реализующем MVC. С такой точки зрения приложение, использующее Ext JS является одним огрмным REST сервисом (хотя требование об отсутсвии состояния здесь не выдерживается). Предположим всё таки, что наш REST сервис удовлетворяет условию простоты. В случае обычной работы web слоя и сервлета контроллера первая часть адреса это "сервер->контроллер", а вторая определяет обработчик, генерирующий ресурс. Параметры запроса мы передаем некоторым СТАНДАРТНЫМ образом. Обратившись к REST сервису мы видим НЕ СТАНДАРТНОЕ описание дийствий обработчика, когда даже смысл использованния HTTP запросов (например, POST) размыт и может быть в разных организациях разным. Но, как уже упоминались количество типов HTTP запросов недостаточно, и мы начинаем добавлять в адрес компоненты, кодирующие нужные операции обработчика и параметры. Ресурсом может быть и документ, и вызов метода, которому могут понадобиться фактические параметры - это ведь типично для сервиса? Поместим их в тело в виде JSON? Какую часть служебной нформации помещать в адрес, а какую в тело? Здорово, что REST сервис может быть реализован  свободным образом! Однако в сложных случаях свобода оборачивается негативными последствиями. Разработка REST сервисов из индустриального процесса превращается в искусство. Бог с ним с функционалом - он зависит от проблемной области, хотя и здесь есть типовые решения (DAO). Суть вопроса также не в способе функционирования микросервисов, а в том, что их много. А интерфейс взаимодействия с REST сервисом зависит от воображения разработчика и плохо поддается стандартизации. К тому же сервисы работают  не только в рамках одной организации и REST вовсю функционируют в глобальной сети. Отказывшись по причине "простоты", желанной свободы, или (извините) моды, от SOAP на смену получили для сервиса неопределенный и почти не поддающийся стандартизации интерфейс. Самое паршивое, когда разработчик полагает, что использует REST, а на смом деле "лепит" для работы в глобальной сети что-то собственное "ужасно правильное", не понимая сути REST, или превращает URL адрес в свалку неструктурированной информации.

поток сознания ок.  ну если вы предпочитаете сложности реализации соапа взамен простоты реста — не используйте рест

Ну так и надо было тип запроса в URL передавать.


Сервисом не является, является клиентом.



По поводу остального tl;dr: ты не понимаешь сути REST. Ты считаешь что это некий стандарт, который все за тебя расписывает: этот параметр туда, этот сюда и т.д. А REST это просто некая парадигма, как нужно делать. Есть рекомендации и есть здравый смысл - всё, хочешь пользуешься, не хочешь не пользуешься.

Когда писал о приложении, использующем Ext JS имел в виду серверную часть.

Ага, кажется вопрос окончательно решен: у меня бессмысленный поток сознания.

И в рамках этого потока я думаю, что SOAP не так уж и сложен, как его малюют. Однако, гибкость его в рамках современного состояния явно недостаточна. REST, как уже было отмечено парадигма, а не стандарт. При этом некоторые разработчики, которые пытаются следовать его идеологемам буквально, наталкиваются на существенные проблемы (см. дискуссии в Интернет - хотя бы комментарии к статье, на которую ссылался). 

Основная масса разработчиков под REST понимает "пиши, что хочешь, только назови это REST" - очень продуктивная парадигма.