Comments 153
Прочитал — и пошёл в исходную статью, проверить дату. Пока все топят за переход с REST на GraphQL, автор узнал, что кроме SOAP бывает ещё и REST.

REST и "то, что люди делают, называя REST" — это две большие разницы. :) Если люди будут понимать graphql так же, как сейчас понимают REST, мне уже заранее страшно.

GraphQL не менее замороченная фигня, которая сулит ровно ту же боль, только с иного ракурса.
По мне так GraphQL прекрасно ложится в эту статью про REST как перерождение SOAP, потому что GraphQL c его схемами и описаниями данных — это WSDL только в профиль.
REST(ful) — это то что случается когда язык созданный для того чтобы обезьянка танцевала становится индустриальным стандартом
Критиковать каждый может. Если у меня клиент — браузер, то либо REST Api, либо GraphQL (в связке с apollo). Выбор не велик.

Код для Angular из apollo:
const CurrentUserForProfile = gql`
  query CurrentUserForProfile {
    currentUser {
      login
      avatar_url
    }
  }
`;


Если у меня клиент — браузер, то либо REST Api, либо GraphQL

А почему? Что мешает использовать любой велосипедный протокол поверх HTTP?

Не прочувствовал проблемы.


Никаких стандартов, никаких точных спецификаций.

HTTP — стандарт, хорошо задукоментированный. Пути, как правильно, достаточно понятны. Хочется большей точности — пишите документацию, тут никак не отвертишься, ни в случае с REST, ни в случае с чем-то ещё — ни SOAP, ни GraphQL не покроют всех деталей.


Какую URL-endpoint вы присваиваете каждому «ресурсу»? Да, это просто, но приходится делать в любом случае. [...] Как вы сопоставите точные функции из приведённого примера с CRUD-операциями?

Здесь автор предполагает, что API просто оборачивает какую-то БД, где есть какие-то таблицы-ресурсы. Но API может делать много чего другого — запускать процессы на кластере, делать вычисления, обращаться к другим API и т.д. Какой протокол покроет это? XML-схема здесь чем-нибудь поможет?


Паршивое решение: ваш nginx был ошибочно сконфигурирован на один час, так что пользователи вашего API получают только ошибки 404 и вычищают сотни аккаунтов, думая, что они удалены…

Откройте для себя www.pingdom.com иди десятки подобных ресурсов. Сайт может упасть по десяткам причин, с таким же успехом можно делать быстрые правки по SSH прямо на сервере и не проверять результат.


Хотите с помощью PUT обновлять свои ресурсы? [...] Хотите для обновления своего ресурса использовать PATCH? [...] Хотите удалять ресурсы с помощью DELETE?

Ок, если такие проблемы, используйте везде POST. Не по стандарту? Да, наверное, и что? Покрыть стандартом 100% случаев невозможно, но вас никто и не заставляет в точности следовать стандарту. REST вполне неплохо описывает то, что от вас будут ожидать пользователи, например, что GET не будет менять состояние, что DELETE удалит объект и т.п., но если в некоторых случаях такое поведение невозможно, пометьте эту часть в документации жирным.


В общем и целом видно, что автор пришёл из определённого окружения, где SOAP хорошо работал, а REST работает хуже. Ну ок, нет серебрянной пули и всё такое. Но кроме окружения автора есть ещё сотни и тысячи вариантов использования, где REST если не оптимален, то как минимум лучше тяжеловесных решений типа SOAP.

Товарищи, которые минусуют, вы хоть комментарии какие-нибудь оставьте. А то видно, что вы не согласны, но с чем и почему, остаётся только догадываться :)

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

Эээ, так а о чём тогда статья?


Я, в основном, реагировал на конкретные фразы в статье, которые у меня вызвали недоумение и ощущение "запугивания" читателя. Ну вот, например:


Использовать HTTP 404 Not Found для уведомления об отсутствующем ресурсе — звучит чертовски по-RESTful, верно? Паршивое решение: ваш nginx был ошибочно сконфигурирован на один час, так что пользователи вашего API получают только ошибки 404 и вычищают сотни аккаунтов, думая, что они удалены…

Речь, судя по всему, идёт про внешние ресурсы а-ля интернет-магазинов, т.е. не про внутренние сервисы, которые общаются автоматически. Соответственно, девопс или админ продеплоил конфигурацию nginx, не проверил, работает ли оно, на сервере не был настроен алертинг и никакие внешние сервисы типа pingdom? Ну ок, не очень ответственный человек, но поверим. Но, если пользователи не могут войти в свой аккаунт, то как они "вычищают" их? Т.е. вся ситуация выглядит притянутой за уши.


Ну или вот:


В результате, как и большинство пользователей REST, вы, вероятно, для выражения исключений в своём приложении используете случайные HTTP-коды вроде HTTP 418 I’m a teapot или вообще неприсвоенные номера. [...] Удачи вам в общении с такими API из автономных программ.

За последние 3-4 года я написал штук 20 REST-сервисов, и ни в одном не использовал "левые" коды, как раз потому что к моим сервисам обращались автономные программы, которые по коду понимали, что делать дальше — подождать (503), запросить авторизацию (401 / 403), создать тикет (500) или нормально обработать результат (200). Люди, с которым я работал, тоже никогда так не делали. Публичные API, с которыми приходилось работать, тоже использовали коды по назначению. Тем не менее, автор делает необоснованные предположения, либо чтобы усилить свой аргумент, либо потому что привык к другой среде, о чём я и написал в заключении.


Я писал сервисы, которые общались друг с другом по SOAP, REST, Websockets (включая подпротоколы), голому TCP, AMQP, NATS, Kafka и т.д., поэтому, наверное, я всё-таки немного в теме. И даже если допустить, что статью целиком я не понял, отдельные фразы вроде указанных выше интерпретировать иначе чертовски сложно.

Но, если пользователи не могут войти в свой аккаунт, то как они "вычищают" их? Т.е. вся ситуация выглядит притянутой за уши.

Все locations работают, кроме одного. Но самого важного для пользователей.


Как раз потому что к моим сервисам обращались автономные программы, которые по коду понимали, что делать дальше — подождать (503), запросить авторизацию (401 / 403), создать тикет (500) или нормально обработать результат (200)

А как они обрабатывали стандартные и полустандартные коды? Хотя бы 201, 204, 409, 422? Как обрабатывали 302 — постандарту или как браузеры?

Все locations работают, кроме одного. Но самого важного для пользователей

Опять же, речь ведь идёт про внешний сервис, с UI, пользователями и всем таким? Значит пользователь не знает ни про какие locations, ему нужно войти в свой аккаунт, найти кнопку "delete my account" и нажать на неё. Но войти он не может, потому что 404.


Автоматические программы могли бы знать про locations, но если такая программа делает DELETE /myobject после того как GET /myobject вернул 404 — это тоже, мягко говоря, странное поведение.


А как они обрабатывали стандартные и полустандартные коды? Хотя бы 201, 204, 409, 422? Как обрабатывали 302 — постандарту или как браузеры?

302 для API ни разу не использовал — это, всё-таки, публичный контракт, и в эндпойнтах лучшше поддерживать обратную совместимость. Если очень хочется переместить ресурс, то лучше увеличивать версию API.


Остальные коды обрабатывались в соответствии с логикой, описанной в документации. Если какой-то код не описан в документации, то и обрабатывать его не надо.

делает DELETE /myobject после того как GET /myobject вернул 404 — это тоже, мягко говоря, странное поведение.

Делает DELETE /user/:id после того как GET /user/:id/some-important возвращает 404

Из реальной жизни? Я зарегистрировался в игре, игра не работала, я закрыл вкладку, но начали спамить, я нажал ссылку удалить аккаунт.

Нажали ссылку где? В письме GET запросом по URL без аутентификации в аккаунт?


За свою жизнь я не видел ни одного ресурса, где аккаунт можно было бы удалить просто нажав кнопку. Обычно для этого нужно войти в свой аккаунт и в "опасной зоне" своего профиля нажать красную кнопку, а затем ещё и подтвердить паролем. И даже после этого аккаунт обычно помечается как "удалённый", но у пользователя есть N дней, чтобы отменить действие.


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

Аутентификация, как я понимаю, была по одноразовому токену, по GET перешёл в настройки профиля, на страниц подписки, но выбрал удаление аккауунта.


Я вам привожу пример, как из-за ошибок на стороне сервера пользователь уходит с ресурса навсегда.

А пример нужно той ситуации, где 404, возвращенный прокси-сервером, приводит к некорректному поведению клиентского приложения.

так что пользователи вашего API получают только ошибки 404 и вычищают сотни аккаунтов, думая, что они удалены…

По-моему, тут речь непосредственно о том, что думают пользователя, получая 404.

Нет.


so your API consumers got only 404 errors and purged hundreds of accounts, thinking they were deleted

API consumer — это не пользователь, это потребитель API (программа). А purge — это не (совсем) удаление.

Да все в порядке с переводом! Пост-то про API, а значит если написано «пользователь» — подразумевается «программа-пользователь» или «система-пользователь».

"клиент" или "потребитель" обычно употребляется в контексте API, а "пользователь" — разработчик

Имеется в виду удаление связанных аккаунтов на другом сервисе-потребителе, или я что-то не понял?
Пользователи всегда уходят с ресурса, если он работает с ошибками. Не важно что там под капотом.
Но, если пользователи не могут войти в свой аккаунт, то как они «вычищают» их? Т.е. вся ситуация выглядит притянутой за уши.

Этот пример просто показывает, что смешение транспортного уровня и уровня логики приводит к такого рода ошибкам. А вычистить из за такой ошибки пользователей вообще ничего не стоит, потому что где-то на другом серваке стоит другой сервис, который синхронизирует пользователей себе локально, для чего обращается к нашему и если видит, что его уже нет, то удаляет и у себя, например. Это взятый из головы пример, но в целом вероятный. Суть проблемы в том, что вызывающий скприт не понял, что тот 404 который пришел, он совсем не про то.
как раз потому что к моим сервисам обращались автономные программы, которые по коду понимали, что делать дальше

Какой http-код вы возвращаете если вам нужно сказать клиенту, что транзакция длилась слишком долго и была отменена?
Публичные API, с которыми приходилось работать, тоже использовали коды по назначению.

Всё верно, проблема только, что на все случаи кодов нет и особенно для более сложных api всё равно приходится что-то придумывать сверх того, что есть.
… либо потому что привык к другой среде, о чём я и написал в заключении.

В заключении вы говорите о том, что автор привык к soap, хотя автор недвусмысленно намекает, что проще было бы место soap-а и rest-а использовать какие-то простые http-rpc. Что наводит меня на мысль, что вы или не знаете, что имеет ввиду автор или просто не читали, но осуждаете.
И даже если допустить, что статью целиком я не понял, отдельные фразы вроде указанных выше интерпретировать иначе чертовски сложно.

Но возможно местами, если всё же вникнуть в написанное.
другой сервис, который синхронизирует пользователей себе локально, для чего обращается к нашему и если видит, что его уже нет, то удаляет и у себя, например.

Так он удаляет у себя, а не на нашем сервере. К тому же, если он удаляет пользователя локально, значит для него это что-то вроде кеша и он может потом ещё раз сделать GET и всё восстановить.


Я понимаю, что автор хотел показать разницу между транспортным и логическим уровнем, но в этом треде уже довольно много комментариев, но пока никто так и не привёл более или менее реального пример, когда описанная ситуация могла на самом деле случиться. Теоретически — это возможно, на практике — ситуация надуманная.


Какой http-код вы возвращаете если вам нужно сказать клиенту, что транзакция длилась слишком долго и была отменена? [...] Всё верно, проблема только, что на все случаи кодов нет и особенно для более сложных api всё равно приходится что-то придумывать сверх того, что есть.

Лично я бы использовал 422 (unprocessable entity), но если сомневаетесь, возвращайте 400 (bad request) и пояснение. Расспространённое заблуждение, что HTTP коды должны описывать все возможные ситуации и ошибки, но по сути это классы ошибок, а внутри ответа уже может быть указана точная причина. Это ничем не отличается, например, от классов исключительных ситуаций (скажем, OSError или LookupError в Python), которые покрывают сразу массу возможных причин, а точная проблема диагностируется по полям эксепшена.


В заключении вы говорите о том, что автор привык к soap

Не совсем, я говорил про окружение, из которого пришёл автор. Насколько я понимаю, автор пишет с точки зрения энтерпрайз приложений и сложных интеграций. Это не публичные сервисы, кто попало к ним не обращается, а если уж используют, то сразу много всего. SOAP был не так уж и плох для таких интеграций, *RPC во многом повторяют возможности SOAP, по крайней мере, автор прямо говорит о том, что старался перейти на RPC в своём домене.


Но есть масса других доменов, где требования совершенно другие. От GitHub API мне не нужны все 250 эндпойнтов, я хочу просто доставать количество звёзд проекта. От StackOverflow мне не нужен полноценный клиент, мне достаточно уметь считывать текст вопроса и теги. С другой стороны, мне это надо делать из разных языков, в т.ч. тех, для которых нет *RPC клиента. И если я смогу для своего запроса использовать обычный, доступный везде HTTP с уже знакомой семантикой (знакомые "глаголы", коды, с которыми я уже работал и т.д.), то это, как ни крути, большой плюс.

Так он удаляет у себя, а не на нашем сервере. К тому же, если он удаляет пользователя локально, значит для него это что-то вроде кеша и он может потом ещё раз сделать GET и всё восстановить.

Вообще не факт. Допустим, он хранит у себя какую-то информацию, пивязанную к пользователю, например, список его покупок, или сообщений на втором ресурсе, или каких угодно других обрывков информации. И это будет удалено. Откуда восстановится эта информация? (В общем случае, не рассчитывая на резервное копирование или удаление через отметку).
Хотите с помощью PUT обновлять свои ресурсы? Ладно, но Пресвятые Спецификации утверждают, что ввод данных должен представлять собой «полный ресурс» (complete resource), т. е. нужно следовать той же схеме, что и у вывода данных с помощью GET.


REST требует, чтобы каждый запрос содержал в себе необходимую для выполнения информацию. Если для корректного апдейта требуется только 2 поля, то шлите только 2. В чем проблема?
REST не привязан к HTTP. Вы хоть почтовыми голубями REST можете сделать. Главное чтобы ресурсы имели уникальные идентификаторы и запросы содержали все необходимое для выполнения этого самого запроса.

Нарушает семантику PUT в HTTP как в прикладном протоколе. Если мы его используем как транспортный (а де-факто почти всегда так бывает в "REST API"), то пофиг на семантику :)

… до тех пор пока посередине не окажется особо хитрый прокси-сервер.

Я тут писал в комментах, что как пуризм, так и пофигизм должны иметь границы, определяемые практичностью.

Семантику PUT нарушает, так как надо использовать метод PATCH.
В статье то же самое написано. Но там дальше про недостатки PATCH тоже есть…
А кто-то может простыми словами объяснить чем плох RPC? Ну и, соответственно, лишен ли REST этих недостатков?
UFO landed and left these words here

Он с таким же успехом вместо "кеширование" мог написать "зеленый", содержательность не пострадала бы.

Если под RPC иметь ввиду SOAP, то его ругают за то, что аналог с REST будет легче весить (сам запрос и ответ).
А если говорить о настоящем RPC, особенно для общения между однотипными системами типа RMI у Java, то он просто не нужен для того говнокода, который сейчас пишут.

чем плох RPC? Ну и, соответственно, лишен ли REST этих недостатков?

RPC в Java не совместим с RPC в С# и т.д. REST всего лишь оказался стандартом, который поддерживают так или иначе все, соответственно нет если есть несколько микросервисов Java на REST, вы можете переписать одни из них на GO и все остальные этого не заметят. В RPC вы жестко привязаны к языку (и даже хуже иногда к конкретной версии языка, скажем, при передачи классов от Java 8 к Java 6 могут быть проблемы).

Вообще любой простой текстовый протокол мог бы заменить REST, просто REST оказался более популярных (и достаточно простым чтобы написать даже на асемблере и достаточно упорядоченным, чтобы не превратиться в полную анархию)
REST всего лишь оказался стандартом

REST — не стандарт, а архитектурные принципы построения распределённых систем. Принципы REST широко использовались для создания протокола самой популярной, наверное, из них, веба. Протокол этот известен как HTTP. Но REST может быть реализован без HTTP, либо используя его как транспорт.

REST — не стандарт, а архитектурные принципы построения распределённых систем.

Вы же понимаете, что это по сути одно и тоже? Ну да, формально, никто не мешает отправлять письма по почте и называть это REST, но у построения RESTfull сервисов есть вполне определенные правила и c вашим сервисом не смогут работать, если вы не будите им следовать. Де-юре, не стандарт, де-факто — вполне, стандарт.

Принципы REST широко использовались для создания протокола самой популярной, наверное, из них, веба. Протокол этот известен как HTTP.

Так наоборот же, сначала был веб/HTTP, а потом REST. Тут уж скорее REST был создан по подобию HTTP, а никак не наоборот (хотя они вообще-то о разном).

Но REST может быть реализован без HTTP, либо используя его как транспорт.

Спасибо, кэп. По-моему, тут всем прекрасно известно, что такое REST. Только к чем это?
Вы же понимаете, что это по сути одно и тоже?

Я понимаю, что чаще всего когда говорят о REST, то имеют ввиду попытки натянуть предметную область на семантику HTTP. Или наоборот. И говорят так, чаще всего, по незнанию, свято веря, что DELETE /api/v3/users/1/password это не просто REST, а единственная его правильная реализация.

RPC в Java не совместим с RPC в С# и т.д.

Вообще-то RPC — это remote procedure call. Какая такая Java 6 или 8, о чем вы? Это не Java ни разу. Более того, такого стандарта вообще нет, есть SOAP и как его вариация — сообщения SOAP для вызова процедур/методов, с указанием метода и параметров, и возвратом результата (не путать например с Document стилем, когда вы просто посылаете XML, не вызываете непосредственно никакой метод, не передаете параметры, и в общем случае не ждете результата — потому что ваше сообщение могут просто переслать куда-то еще, без ответа). Т.е. SOAP — это не RPC, в общем случае.


И они вполне себе совместимы между разными языками, если не пытаться передавать внутри сериализованные Java объекты, и не надеяться, что C# их успешно прочитает.

Вообще-то RPC — это remote procedure call. Какая такая Java 6 или 8, о чем вы? Это не Java ни разу. Более того, такого стандарта вообще нет,

Да, это не стандарт. Это набор разных стандартов под общим именем, например Java RMI.

есть SOAP и как его вариация — сообщения SOAP для вызова процедур/методов… Т.е. SOAP — это не RPC, в общем случае.

Так вы уж определитесь RPC это или не RPC.

И они вполне себе совместимы между разными языками, если не пытаться передавать внутри сериализованные Java объекты, и не надеяться, что C# их успешно прочитает.

Кто они-то? SOUP, вы сами сказали не RPC, тогда кто с кем совместим? Есть Java RMI — не совместим не с чем кроме Java, есть DCOM — чисто для Microsoft систем, есть куча других RPC протоколов, которые тоже со своими ограничениями и если вы придумаете язык НЯ, естественно там они работать не будут пока кто-то не напишет их реализацию, а REST работает повсеместно (и реализация его при умении работать с сетью в принципе дело простое). Более того язык НЯ может вообще не содержать всех тех сущностей, что хочет какой-нибудь SOUP (ну скажем мы придумали язык без классов и функций, аля SQL), как он будет работать с RPC?

Если бы вы почитали, что такое SOAP, если бы вы это сделали, вы бы знали, что RPC — это его частный случай. Да, SOAP это не RPC, это намного больше. Но вариант "просто RPC" он вполне себе умеет, и более чем совместимо между разными языками.

что RPC — это его частный случай.

Так все наоборот, SOUP можно назвать одним из RPC протоколов. Одним, скажем, Java Remote Method Invocation это тоже RPC протокол и он не будет совместим ни с чем другим.

SOAP это не RPC, это намного больше.

SOUP в статье рассмотрен отдельно. Речь шла о RPC, кроме SOUP.

Если бы вы почитали, что такое SOAP, если бы вы это сделали, вы бы знали

Думаю, мне хватит, что я десяток лет SOAP сервисы писал.

Но вариант «просто RPC» он вполне себе умеет, и более чем совместимо между разными языками.

Любыми языками? Сможете написать обмен между Brainfuck и С#? Ну или между ассемблером и PL-SQL? Даже чисто теоретически.

А почему вы так последовательно пишете SOUP, когда все остальные пишут SOAP?

Думаю, мне хватит, что я десяток лет SOAP сервисы писал.

В том-то и дело, что SOAP — это не только веб-сервисы...

Блин, да дело в том, что SOAP это не только RPC. Ведь RPC — это вполне узкое понятие, вызов процедуры. Т.е. предполагается имя процедуры, и параметры. И неявно предполагается, что это синхронно. При этом SOAP не требует (ну скажем так, уже давно не требует — начался-то он все-таки с XML RPC) того, чтобы указывать процедуру, и передавать собственно параметры. Т.е. передается просто некий XML, с которым получатель делает что угодно — возможно ничего не вызывает. Делая это асинхронно, не возвращая ответа (одностороннее взаимодействие), и т.п. А еще можно передавать attachments, чего процедуры никогда не умели.

Я не знаю, что вы там писали, я вижу лишь ту чушь, что вы пишете здесь.


Есть Java RMI — не совместим не с чем кроме Java,

А ничего, что я еще лет 10 назад успешно вызывал RMI из C#?


есть DCOM — чисто для Microsoft систем

А ничего, что DCOM и COM успешно доступны из Java? И опять же — я это лично делал, и достаточно давно уже. Причем и то, и другое легко гуглятся, ежели вдруг нужно.


Ваша квалификация в данном вопросе — она видна невооруженным глазом.

Просто ради интереса: можно ли из Java-софта, работающего под LInux использовать DCOM-компоненты, работающие на удаленном сервере под Windows, не настраивая ничего особо на стороен последнего и не реализуя самостоятельно весь DCOM проткол на Java? А если можно, то кто предоставляет адаптеры — MS, Oracle или третьи лица?

На этот вопрос нет простого ответа.


Ну зачем же самостоятельно? Уже давно сделали.


Короткий ответ такой — я бы не стал на вашем месте этого делать, по чисто практическим причинам. Ну т.е., скажем, ничего особо настраивать не нужно — если вам не нужна безопасность. А если она будет нужна (а скорее всего вы захотите какую-никакую аутентификацию и авторизацию), то у вас под линуксом не такой уж широкий выбор. По сути — керберос.


MS, Oracle или третьи лица

Третьи лица. И некоторые решения за деньги. Но в комплект Weblogic, например, много лет входило все нужное (видимо, и сегодня входит). А он бесплатен для разработки, т.е. попробовать можно не оплачивая. Я это делал очень давно, поэтому могу кое-где ошибиться, но кажется мне, что сегодня DCOM есть в JNA (не путать с JNI). Это продукт а) открытый и б) свежий.


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


Я бы смотрел (собственно, и много лет назад вывод был примерно такой же) на связь на другом уровне. Чтобы именно DCOM из процесса убрать. Чтобы сетевое взаимодействие происходило по простым стандартным открытым протоколам. А COM уже внутри Windows, стандартными средствами для этой системы.


Ну типа .Net Remoting, например, да хоть бы и REST.

но кажется мне, что сегодня DCOM есть в JNA (не путать с JNI).

Вам кажется, JNA это способ работы с библиотеками на С++ и ассемблере (в том числе библиотеках ОС), то есть DCOM там «есть» пока вы запускается JNA в Windows и есть он только потому что JNA обращается к виндовым библиотекам. Если вы считаете иначе дайте ссылку на любое решение, которое позволило бы запустить DCOM в Linux. То есть как я и говорил COM и DCOM это чисто технологии Windows платформы.

DCOM и COM не надо путать, вам COM под линуксом никто не обещал (да вы его и не просили).


JNA обращается к виндовым библиотекам? Хм. И где бы оно их взяло под Linux, интересно? В то время, как linux Java клиент, который работает с Excel, который в свою очередь работает на другой машине под Windows — вполне себе реальность.

А ничего, что я еще лет 10 назад успешно вызывал RMI из C#?

А вот тут подробнее, да существует RMI в .Net, но речь шла о Java RMI (в котором использует в том числе Java сериализация объектов). Вы реально соединяли C# с Java через Java RMI? А как Java сериализация объектов работала в C#? Дайте, плиз, ссылки на используемые библиотеки, так как ничего не нагугливается. Реально интересно.

DCOM и COM успешно доступны из Java

Успешны доступны из Java, запущенной на Linux или FreeBSD? А дайте ссылку на библиотеку, мне очень интересно (без сарказма). Java, запущенная в Windows, конечно, может через C++ библиотеку без проблем обратиться в любому API ОС, а вот как это сделать кросплатформено.

Ну я же вам сразу сказал — нету особых проблем с сериализацией. Ну то есть, если вы на одной стороне сериализуете некий параметр, для которого нет аналога на другой, потому что другая сторона про такой тип данных/класс не знает — то ясное дело, даже в случае Java RMI -> Java RMI вы можете поиметь проблемы.


Но это как бы общая проблема любого удаленного, даже не кроссплатформенного взаимодействия. Нужно строить API так, чтобы обмениваться строками, числами, или обеспечивать, чтобы обе стороны умели десериализовать любую хрень, которая может прилететь. Т.е. по сути — надо на стороне C# реализовать десериализатор для достаточно широкого набора базовых классов.


Что же до реализаций — то IKVM .Net, JNA, большинство этих проблем решают.


К любому API — это слишком сильно. Вы не можете вызывать нормально API, где нужны скажем хэндлы файлов или сокеты — потому что файл не передается через сеть. Вот COM и DCOM практически гарантирует, что таких параметров не будет, потому что как раз задуманы как кросс-языковые средства. С COM из Java вообще не сложно, реализаций больше чем одна.

Что же до реализаций — то IKVM .Net, JNA, большинство этих проблем решают.

Но ведь IKVM .Net это по сути Java машина работающая на Net? То есть как я и говорил Java RMI это средство обмена между двумя виртуальными Java машинами (просто одна запущенна на .Net).

Вот COM и DCOM практически гарантирует, что таких параметров не будет, потому что как раз задуманы как кросс-языковые средства. С COM из Java вообще не сложно, реализаций больше чем одна.

Это понятно, но можете подсказать реализацию COM и DCOM, которая позволит наладить интеграцию между двумя Linux серверами с запущенной Java без всяких решений от Microsoft?
Но ведь IKVM .Net это по сути Java машина работающая на Net? То есть как я и говорил Java RMI это средство обмена между двумя виртуальными Java машинами (просто одна запущенна на .Net).

IKVM .Net — да, почти JVM, но другие реализации RMI ничего подобного не содержат. И да, решения эти гуглятся за пять минут, и их значительно больше двух.

Мне кажется, Вы просто не понимаете разницу между бинарным и тестовым форматом.

Если оформлять передачу изменений в системе через HTTP-глаголы, выразив это состояние в терминах REST-ресурсов, то у вас уже будет концептуальный каркас для внедрения в свою архитектуру системы кеширования и обработки ошибок (причём это получится красиво в отдельные слои выделить, в которых «смысл» кешируемых ресурсов и ошибок будет выражаться лишь набором параметров инвалидации и человекопонятных описаний ошибок). Всё это можно сделать и без REST-а, но вылизывая свою архитектуру и устраняя из неё противоречия вы сами рано или поздно придёте к семантическому аналогу REST-а. REST — это как бы не набор инструментов, а, скорее, учебник по истории решения типовых проблем в проектировании распределённых приложений. Ценность не в побайтовом следовании спецификации (хотя и будет удобным воспользоваться уже готовыми механизмами HTTP, поддерживаемыми промежуточной инфраструктурой провайдера типа проксей и CDN), а в общем понимании архитектурных принципов, позволяющим реже заходить в тупики противоречий при проектировании.

Если вам достаточно RPC и непонятны плюсы REST, не переживайте, пользуйтесь тем, что понимаете. REST, по сути, становится остро актуальным лишь в больших проектах (распределённых и по серверам, и по командам разработчиков всех подсистем), а в малых проектах с командой на 1-3 программиста вы можете даже и не столкнуться со всеми теми ужасами согласования, которые решает REST.
Если простыми словами, то, тут есть два основных момента, и один второстепенный, где REST должен отличатся в лучшую сторону.

1. REST является platform agnostic способом общения, который требует от платформы только поддержки HTTP. На одном конце может быть С++ сервис, а на другом Javascript, если они оба могут в HTTP, значит у них уже из коробки общая система управления кэшированием, редиректов, повторных запросов, ошибок, аутентификации и прочих вещей которые уже включает себя HTTP.

2. Инфраструктура. Между сервисами общающимися с помощью HTTP/REST, может быть легко построено любое количество инфраструктуры отвечающей за балансировку, проксирование, кэширование, безопасность, логирование, редиректы, нетворкинг и многое другое, без каких либо изменений в коде сервиса. Так как почти все инфраструктурные сервисы/тулзы поддерживают HTTP, a REST по своей природе опирается на все возможности HTTP, а не просто использует его как транспорт.

3. HATEOAS

PS: я не сторонник REST. Но, если мне нужно будет работать с legacy инфраструктурой, я предпочту REST.
А RPC разве не может работать через HTTP? Как-то все их постоянно противопоставляют…
RPC работая через HTTP не оставляет никаких подсказок промежуточным серверам относительно возможностей того же кеширования. Как правило вся семантика ограничивается операцией POST в которой по умолчанию кеширование ответов запрещено.

Поэтому считается что в случае идеального REST правильно настроить кеши проще.

1 и 2 по сути применимы к чему угодно, использующему HTTP как транспорт.

Обычно, чтобы понять назначение RPC запроса, нужно научит ифоаструктуру хотя бы на базовом уровне понимать тело этих запросов. Возьмём самое простое — кэширование. В http/rest у идемпотентных запросов есть явные характеристики, и большенство из них можно смело кэшировать. У RPC запросов, не ясно, есть ли у метода side effects и является ли он безопасным для кэширования. В этой ветке хорошо заметили — RPC почти не оставляет на уровне HTTP подсказок о себе, для него, это всего лишь транспорт.

Ну, это от реализации зависит. Хотя, да, люди бросаются в крайности обычно: или стараются натянуть предметную область на семантику HTTP чуть более чем полностью, изобретая, например, несуществующие ресурсы или подресурсы, для обхода сильного ограничения на количество доступных действий, или вообще игнорируют возможности, предоставляемые HTTP, заботясь только об обходе нежелательных им особенностях, типа кэширования.

или на новичков вроде GraphQL и gRPC для публичных API…
Только для публичных API?
Мне вот интересно зачем современные программисты усложняют себе жизнь всякими концепциями вроде GraphQL или REST. Основная задача программистов сделать быструю, качественную и легко поддерживаемую и расширяемую систему. Очевидно что REST за пределами CRUD не может с этим справиться, хотя бы потому, что на каждый чих нужно добавлять новый url, в котором часто используется только один вызов (чаще всего GET или POST) — в результате получается тот-же RPC, но под соусом модного RESTа и с кучей проблем. GraphQL неоправдано сложен и на мой взгляд недостаточно безопасен. Он как швейцарский нож — вроде можно сделать много вещей, но если ты делаешь это часто, то лучше иметь отдельный нож, пилу и ножницы. Хотя для прототипирования очень даже неплох… SOAP сильно бюрократизирован и тяжёл. Иногда его можно применять — например для межсистемного взаимодействия или когда можно описать wsdl-ку и предоставить её другой компании для интеграции. Но если честно, то все преимущества SOAP можно реализовать и на REST. При всей своей непопулярности сейчас RPC, а именно json-RPC является идеальным решением. Для себя часто применяю комбинацию REST и JSON-RPC, где REST использую для CRUD операций, а для всего остального — JSON-RPC.
Как вы решаете проблему отдачи данных для разных платформ? для мобильников нужны одни данные, для веба нужны другии.
Способов много, можно добавить ещё один REST сервис (для CRUD). Можно выставить новый сервис (т.е. метод/процедуру), можно добавить параметр в существующий сервис. Можно определять по полям в заголовке запроса от кого пришёл запрос (наверно самый правильный вариант).
Нет, зачем для каждой платформы. Только для сервисов (т.е. что это за сервис и какие параметры принимает и что в результате выдаёт). Чаще всего достаточно добавить /// комментарий к методу и сгенерировать потом документ на их основе.
А вообще — это частный случай (разных выдач для мобилок и десктопов обычно не так много). Иногда можно отдать избыточную информацию для мобилки. Иногда можно переписать сервис, чтобы потом десктоп дозабрал недостающие данные. Можно применить что-то вроде OData или GraphQL (но не ко всей системе, а только для этого сервиса).
Нет, зачем для каждой платформы.
Потому что для разных платформ возвращаются разные данные + Клиент может сгенерировать код по документации
SOAP, REST… Послушайте реальную историю двух-недельной давности, которая со мной приключилась.

Новый супер-важный клиент (НСВК):… ну и вот примеры запросов ответов которые вы должны нам слать (приаттачивает какие-то непонятные файлы со строками, похожими на команды модема)
Я: че это за Х?
НСВК: ну как же, это ж EDI, пфф…
Я: послушайте, мы поддерживаем SOAP, REST, JSONRPC…
НСВК: нет, мы работаем только с EDI
Я: вы хотите что бы мы реализовали у себя на стороне поддержку этого ммм… протокола? Посоветуйте хотя бы какие-то оббертки совместимые (по опыту с SOAP знаю что не каждый клиент понимает какждый сервер и т.п.), я вот тут нашел на питоне bots, но он страшный какой-то (там зачем-то ему нужен сервер на джанго чтоб конвертить хмл в EDI)…
НСВК: (приаттачивает непонятных людей в СС с мейлами из OpenText)
Люди с мейлами из OpenText: здравствуйте, мы компания OpenText, крупнейший интегратор EDI, приходите на наше демо

Демо:
Мы многомиллиардная корпорация (действительно, слайды с ревеню зашкаливающие), мы нарисовали схему, вот тут вы, тут мы, а тут ваш НСВК.
Заманчивый слайд с ценами, всего порядка нескольких десятков К долларов с лица (включает стажировку и курсы специалиста по настройке конвертора ХМЛ в EDI).

Занавес.

А вы говорите REST или JSON-RPC…

Тоже работал над EDI -> XML и наоборот, как же я ненавидел этот проект!!!

Тоже с EDI работаю, у нас REST еще не изобрели. Варианты интеграции SOAP или файлики на FTP сервере которые по интервалу забираются =)
При чем что-то менять по технологиям ни в какую, мягко говоря очень консервативный подход.

У нас попроще, делали консольную утилиту на джаве используя код из MapForce, которая собирала все файлики из директории и ложила результат в отдельную папку

EDI любят всякие финансисты, так что с ним придется жить.
В муле есть коннектор. В принципе, он и закрывает у нас все вопросы по теме.
Ну, одно другого не отменяет.
На самом деле, если уж по-честному, обленились вы там, ребята.
Все вам на блюдечке подавай.
Стандарт старый, спецификацию в руки, и вперед.
Ничего там сверхъестественного нет.
Ну а курсы и т.д. — это бонус. Хорошо, когда есть.
Я был не против, если бы была либа-оббертка. Но ее нет! Есть какие-то велосипеды под .NET, и монстроузные интеграторы типа OpenText и bots. Стандарт хороший, основан в послевоенные годы (и не менялся), но с другой стороны — для всего хорошего есть куча бесплатных человеческих АПИ, а для EDI нет, там все коммерческое и стоит баснословных денег, это очень подозрительно как-то.
Не, ради двух АПИ городить поддержку EDI, даже ради такого важного клиента, не знаю…
Ну, какие проблемы — напишите и выложите в паблик забесплатно.
Не нашлось видимо пока желающих — жадные все :-).
Насколько я успел понять (глубоко не вникал, конечно), там под каждую интеграцию нужно свою либу писать, универсальный враппер пытались родить на основе каких-то файлов-конфигов мета-описаний, но это все ужас ужасный, зачем?? Нам нужно получить 10 полей и ответить ОК или ошибка, все.
bots этот питоновский, с админкой на джанге…

Представляете, если б для интеграции по JSON-RPC или REST вам на полном серьезе предлагалось поднять у себя особый сервер, пойти в админку, нарисовать там какие-то схемы, соединить все правильно, написать кучу текста мета-описания, все это для того чтобы сгенерить ХМЛ, который потом сможет прочитать ваш софт! В топку весь этот EDI
Представляете, если б для интеграции по JSON-RPC или REST вам на полном серьезе предлагалось поднять у себя особый сервер, пойти в админку, нарисовать там какие-то схемы, соединить все правильно, написать кучу текста мета-описания, все это для того чтобы сгенерить ХМЛ, который потом сможет прочитать ваш софт! В топку весь этот EDI

Вообще-то именно так и работают интеграционные шины (ESB). И в топку нужно выкинуть именно их, а не EDI :-)

Ну как можно любить EDI, не понимаю. Например:

ISA*00*Authorizat*00*Security I*01*Interchange Sen*01*Interchange Rec*170626*1338*^*00501*000000001*0*I*+
GS*SM*Application Sen*Application Rec*20170626*1338*1*T*005010
ST*204*0001
B2**STAN**Shipment Identification Number**TP
B2A*00*LT
L11*DATE: 20170630 TIME: 053000*P8
L11*MEDIUM*AFG
G62*TA*20170626*0*1338
AT5***FUEL SURCHARGE
RTT*CO*999.99
AT5***BASE COST
RTT*CO*9999

Сравните с:
«date»: «20170630»,
«fuel_surcharge»: 999.99,
«base_cost»: 9999

Вы какой вариант предпочтете для интеграции?

Для интеграции с уже готовой системой я предпочту тот формат, который той самой системой поддерживается :-)


Да, то что вы привели — выглядит некрасиво. Но я не вижу технических сложностей ни в том чтобы такое сообщение сформировать, ни в том чтобы его распарсить.

Вы какой вариант предпочтете для интеграции?

Тот, который нужен клиенту и за который платят деньги.
В обсуждаемой ситуации, как видим, такого не наблюдается.
Обсуждается именно «я хочу так, но клиент-бяка не согласен, и плевать, что у него уже тонны софта под этот стандарт написаны».
Так-то, конечно, можно выбрать то, для чего есть готовые библиотеки и для чего решение можно слепить быстро.
Если у клиента тонны софта под EDI, пусть удосужиться написать оббертку человеческую, я уверен они не от нас первых такое услышали (клиент на рынке — с 1993 года, уверен, что их многие посылали за 25 лет с их OpenText-ом подальше).
Наша жизнь слишком коротка, чтобы плодить велосипеды на стандарты 60-х годов в 2017, как-то так…
Если у клиента тонны софта под EDI, пусть удосужиться написать оббертку человеческую

Щито? Клиент нанимает разработчиков, и он им еще должен писать обертки? Потому что они хотят работать по системе тяп-ляп и готово?

Наша жизнь слишком коротка, чтобы плодить велосипеды на стандарты 60-х годов в 2017, как-то так…

Так в чем проблема? Придет другой подрядчик и напишет.
Тут нет отношений подрядчик\заказчик. Есть две компании, одинаковые по сути, и им нужно интегрироваться, взаимовыгодное сотрудничество так сказать…
Ощущение, что говорят два пипла, один про payload, другой про транспортный протокол (т.е. EDI over SOAP/REST и прочее).
А пример этого самого EDI? Ну и потом, а какой-нибудь integration engine использовать не пытались, нет, оно там возможно уже сделано.
Ну вон они пытались пытались продать OpenText решение для интеграции (с курсами, специалистом и всем), не поверите — там два апи по 10 параметров в каждом! У нас подобных (идентичных даже) интеграций десятки, все без привлечения специалистов сторонних и десятков К.
Я: вы хотите что бы мы реализовали у себя на стороне поддержку этого ммм… протокола? Посоветуйте хотя бы какие-то оббертки совместимые

Херакс, херакс и в продакшн не получилось. Верно сказали выше — обленились вы, ребята.
Не минусил если что.
Я не согласен, что по щучьему велению клиента, или за деньги компании, нужно кидаться реализовывать решения любой степени маразматичности. Понятно, что можно прочитать их мануал на 300 страниц, постичь все аббревиатуры и посчитать звездочки правильно и за пару недель наговнокодить энкодеры\декодеры, но я просто не буду этого делать.
Более того — OpenText не заинтересован в таком исходе, их цель — продать своих ребят, свой софт и себя, поэтому никакого содейсвтия не будет.
А мне потом еще месяцами разгребать баги и искать где звездочка пропущена, извините!

Схема, конечно гениальная! Все понимают что EDI — нездоровая хрень и атавизм в 2017, но мы вас всех готовы спасти, только заплатите.
Схема, конечно гениальная! Все понимают что EDI — нездоровая хрень и атавизм в 2017, но мы вас всех готовы спасти, только заплатите.

Есть программисты, которые хотят переписать все с нуля на модном стеке, а есть бизнес, которому лучше держать таких специалистов от себя подальше. Нет смысла сливать уже оплаченный софт, часы разработки в унитаз, из-за того, что кто-то весь такой модный и в белом пальто хочет иметь красивую строчку с модными технологиями в резюме. Здесь устремления конкретного человека-разработчика и бизнеса не пересекаются.
Еще раз — речь идет о двух функциях с нексолькими параметрами в каждой, вся бизнес-логика давно написана. Проблема именно в оббертке над EDI, ее никто не хочет писать (ни мы ни они). И есть компания-интегратор, которая на оббертке зарабатывает огромные деньги. В этом и есть идиотизм ситуации, они сидят на крючке у интегратора и всасывают новых партнеров туда же… вы не сталкивались с ANSI X12, поэтому вам все это кажется странным.
Я сталкивался с кучей разного легаси, в том числе с необходимостью выгрузки данных в 7 битной кодировке, потому что весьма рупная страховая компания в США обрабатывает данные на старом mainfram'е, использующем ее. Странным все это не кажется, legacy — часть жизни. Никто не будет выбрасывать работающее просто «потому что».

Вы не хотите даже при адекватной оплате написать обертку, которые и вы и другие смогут использовать в будущем?

А как же OpenAPI aka Swagger?
Я всю жизнь сидел на SOAP только потому, что не очень удобно писать десериализаторы на клиенте под крупные JSON/XML данные, а тут такая конфетка, что аж руки зачесались применить её в каком-нибудь API.
Swagger — просто интерфейс по сути, который описывает I/O.
Дальше уже обычный REST с PUT/PATH/POST/GET/OPT… etc.

По Swagger / OpenAPI описанию можно генерировать клиента (например), плюс многие библиотеки сразу дают красивый UI с примерами запросов, от чего клиенты обычно в восторге.

Спасибо, но я в курсе.
Пользуемся swagger давно, для API всех букинг проектов.

Этот OpenAPI показал себя в полной мере после появления версии 3. Поддержка версии 2 была уничтожена в Eclipse — поддерживает его одна компания и их не интересует ничего кроме их же SwaggerHub. Фактически OpenAPI/Swagger — проект одной компании. Вторая версия вообще не позволяла описать некоторые важные моменты, третья позволяет, но не реализована для некоторых языков. Дурацкая ситуация — наработано всё под swagger2, а Eclipse ставит пакет для несовместимого swagger3 :) И по сложности от SOAP ушло всё это недалеко.

Поэтому мы забили на REST и перешли на gRPC. Стало гораздо удобнее и однозначнее.

Одно но, он веб как бы не поддерживает. Есть костыли от сторонних разработчиков которые пытаются приспособить его к вебу, но если сам гугл не сделал такой поддержки, значит оно ему и не нужно. gRPC скорее больше нужен как межсервисная коммуникация. Кстати по опыту CLI protobuf-a просто ужасен.

Мы приспособили его к web с помощью grpc-gateway. Да, оно конвертит в тот же пресловутый json, но на стороне сервиса мы все еще пишем api на gRPC и не пытаемся заигрывать с REST. Сейчас также изучаем возможность работы с нативным gRPC на клиенте.


CLI действительно менее удобный. Однако, по сравнению с сваггером (OpenAPI) тут есть вменяемый красивый DSL.

Если честно, я бы просто хотел генерировать модельки описанные в IDL. Если задуматься, имея готовые модели, можно не заморачиваться со спецификой protobuf протокола, и возвращать обычный json из уже готовой модели(так как для json-a у них свои ). Ну а сервисы, можно будет самому написать, без gRPC. Ведь кому-то нужен REST, а имея на руках готовые модели мы точно знаем какой объект нам придёт, за разработчиком остаётся только определить входные точки(endpoint). Кстати, не пробовали ли вы thrift? Ну я нарыл на днях решение от майкрсофта, где есть дженерики. Они, между прочим, тоже решили следовать gRPC.

REST, на мой взгляд — достаточно ущербный стиль взаимодействия, который добавляет больше проблем и неоднозначностей, чем решает. Далеко не любые бизнес-процессы можно выразить с помощью REST: если у вас что-то сложнее чем CRUD, то начинаются проблемы. Ведь в REST мы говорим существительными и оперируем ресурсами. В классическом RPC — глаголами. Бизнес-процессы удобнее выражать глаголами.


Что касается gRPC: у нас много сервисов на разных ЯП и нам удобно:


  1. Описывать API одинаково и на нормальном языке.
  2. Генерировать из него клиенты и серверы. Весь тулинг официальный и активно поддерживается. Сами proto-файлы с описанием сервисов мы подключаем субмодулями в нужные проекты. Все стандартизировано и достаточно удобно. Само API проходит code review.

Честно говоря не очень понял, что имеется в виду под "спецификой protobuf-протокола", т.к. protobuf — это способ сериализации данных со схемой. Лично нам он очень приглянулся из-за его однозначности и удобства для восприятия. Также классная штука oneof: очень удобно возвращать ошибки из метода.


Ребятам на фронтенд мы тоже даем читать обычные proto-файлы. В них есть и информация о том, как вызвать метод по http и все структуры прозрачно конвертируются в json. Это все вместо (имхо), совершенно неадекватного описания web-api через тот же сваггер, которое больно читать.


Также есть реальная надежда на приход gRPC на фронтенд в полном виде. В этом случае у нас все готово: убираем конвертацию в json и все.


Thrift рассматривали. Очень похож на gRPC и на первый взгляд все здорово, но сам проект еле живой и совсем не развивается.

Затянул с ответом, отпуск.
В gRPC мы передаём все данные в бинарном формате, так гораздо эффективнее, для чего собственно proto формат и был создан. В javascript-e из браузера работать с ним от слова почти невозможно, собственно выходит нужно передавать в каком нибудь другом формате. Ну а дальше натыкаемся на ограниченность формата json и самого http протокола, и невозможность напрямую предоставить некоторые типы данных. Для этого даже был создан документ у них в репозитории.
Так что пока gRPC для меня выглядит как идеальное решение для межсервисной коммуникации. Ту а для веба видать пока что лучше swagger-a альтернативы нету.
Нет, и как по мне чрезмерно переусложненно. Наверное имеет смысл в приложениях со сложными запросами. К примеру интернет-магазин со множеством фильтров
REST — это новый SOAP.


Да ну, SOAP тоже иногда нужен и полезен. У Rest своя ниша, у Soup — своя, у RPC и message query — своя. Главный плюс REST — его поддерживают почти все, поэтому любой сервис на REST можно переписать на любой другой язык. Это очень важно для бизнеса и вряд ли другая технология может его там подвинуть.
Паршивое решение: ваш nginx был ошибочно сконфигурирован на один час, так что пользователи вашего API получают только ошибки 404 и вычищают сотни аккаунтов, думая, что они удалены

Паршивое не решение, а конфигурация nginx. Не надо перекладывать все с больной головы на здоровую.

паршивое решение — смешивать бизнес-логику и протокол передачи данных. Давайте уж на команды TCP завязываться, хуле.
Это разные уровни, их нельзя смешивать. Как нельзя смешивать TCP и HTTP.

И уж тем более невозможно уберечься от падения. А обвинять в «криворукости» — это подход прыщавой школоты
Решение в самом деле паршивое.

Представьте, что у вас есть некий охраняемый объект и есть датчик открытия двери. Пусть он нормально разомкнутый, а при открывании замыкает цепь. Реализуется просто — появилось напряжение на вводе — сигнал тревоги. И все хорошо, но если провод поврежден или просто откушен — система не сработает. И можно сколько угодно топать ногами, гневно восклицая, что монтажники — дураки, проложили кабель в видном месте и вообще что он не заминирован и не надо, мол, с больной головы на здоровую перекладывать. Сделать это идеально не получится и все равно система даст сбой рано или поздно. И эта возможность отказа заложена в самой системе, это и есть «паршивое решение».
По мне так самым удобным был wsdl — в xml было описание всех возможных запросов, форматов запросов и ответов, виды ошибок.
И протокол сам следит за корректностью данных, чтобы они соответствовали шаблону. Полный ordnung. Опять же автоматическая генерация кода сервисов на основе этой wsdl
Проблема WSDL даже не в сложности самого стандарта, а в реализациях библиотек, когда какие-то фичи поддерживается, другие — нет. Не от хорошей жизни начали выдумывать Basic Profile…
А XML — да, мне кажется более надежным чем JSON. Поддержка везде, в самых экзотических системах. Нативная поддержка в Java. Для сравнения, JSON схема 4 — все еще в драфте, а библиотека для Java — сторонняя опенсоурсная, распавшаяся в свое время на два не полностью совместимых бранча.
wsdl — это и есть SOUP, который как раз представляют в статье совсем уж пугалом. На самом деле, SOUP при всей своей громоздкости и сложности вполне имеет нишу и все еще жив.

SOUP это операции, порядок, секюрность, транзакции, сложность,
REST — простота, работа с ресурсами, веб,
RPC — завязка на одну технология/язык + производительность.
Message query/RabbiteMQ и т.п. — завязка на одну MQ систему, локальность, надежность и производительность.

У каждой технологии своя ниша.

Нативная поддержка в Java. Для сравнения, JSON схема 4 — все еще в драфте, а библиотека для Java — сторонняя опенсоурсная, распавшаяся в свое время на два не полностью совместимых бранча.

Не одна их много, есть нативная поддержка json в JEE. Да и какая разница, если все равно все пользуются? Как будто последную версию xml java может не поддерживать.
SOUP это операции, порядок, секюрность, транзакции, сложность,

Пока XXE какой-нибудь не встретится в запросе.
И протокол сам следит за корректностью данных, чтобы они соответствовали шаблону.

Не, не следит. Можно иметь WSDL, несоответствующий ему сервис и пейлоад, и все равно все будет работать. Или не будет. Или можно заслать все строго согласно WSDL и получить болт в ответ.

Основная проблема "REST", как я считаю, что мало кто понимает, что HTTP — это уже практически REST API, заточенный под, как ни странно, под веб-странички. Если ваша предметная область плохо ложится на них, то не надо насиловать ни себя, ни HTTP пытаясь натянуть первое на второе, сделайте один или несколько ендпоинтов и используйте HTTP в качестве транспортного протокола, а не прикладного. Прикладной реализовать можно полностью в теле HTTP запроса, можно использовать какие-то другие его части (заголовки, url, query, коды возврата), но не стремитесь соблюдать его семантику больше чем того требуют практические, большей частью технические соображения, типа способность клиента кэшировать HTTP или способность PHP выбирать файлы из запроса.


Нравятся принципы REST — реализуйте API по этим принципам, передавайте от сервера к клиенту представления состояний, не храните сессию на сервере, передавайте все необходимые данные для операции в запросе клиента к серверу и т. п. (6 принципов REST вроде) Но передавайте всё это так, как вам удобно, создавайте свои типы действий, свои схемы идентификации ресурсов и т. д.


Только не надо говорить, что это получится RPC — оперировать вы будете представлениями состояний ресурсов и операций над ними. Что хорошо ложится, кстати, на ООП: состояние ресурса — объект, действие — метод, представление — кастомная сериализация объекта. А RPC — процедурщина :)

используйте HTTP в качестве транспортного протокола, а не прикладного. Прикладной реализовать можно полностью в теле HTTP запроса, можно использовать какие-то другие его части (заголовки, url, query, коды возврата), но не стремитесь соблюдать его семантику больше чем того требуют практические, большей частью технические соображения, типа способность клиента кэшировать HTTP или способность PHP выбирать файлы из запроса.

Тогда уж лучше WebSocketы использовать, зачем гвозди микроскопом забивать…

WebSocketы не везде хорошо поддерживаются, или точнее, много где хуже чем старый добрый HTTP.

А все потому что в реальной жизни гораздо чаще приходится оперировать действиями, а не ресурсами.


Лайк в Facebook, отправка сообщения в Slack, свайп в Tinder, оформление заказа на Amazon или выстрел в какой-нибудь игрушке — все это действия, а не создание или модификация ресурсов.
За ними скрывается куча побочных эффектов типа отправки письма подтверждения или инкремента нескольких счетчиков.


Можно прятать вызов "like(id)" за запросом к "POST /resource/id/likes", но зачем?

А можно сделать


POST /rest-api
Content-Type: application/x.my-cool-rest-api+json

{
  "resource_id": "id",
  "action": "like"
}

и это будет REST :)

Тут идеологи RESTFUL возразят, что, по определению, "REST API" — это API, соответствующее определенным архитектурным требованиям, и не является объектом (поскольку определение описывает не объект, а концепцию).


Вдохновимся CQRS и разделим все на "запросы" и "команды". С запросами в рамках REST обычно проблем ни у кого не возникает, вся (вполне справедливая) критика REST относится к командам. Окей, пусть команды будут ресурсами, и в рамках REST мы создаем команду (которая немедленно выполняется и, выполнившись, удаляется — вот такая деталь реализации ресурса, почему нет?):


POST /commands

{
     "name": "registerUser",
     "params": {...}
}

Напоминает RPC, правда? :-)

Список доступных action-ов?

Почему вы думаете, что если есть POST /rest-api, то результатом GET /rest-api должна быть коллекция тех ресурсов, что созданы постом?
Да, это распространенная практика, но не требование. REST требует, чтобы ресурс можно было идентифицировать однозначно, но не требует совпадение URL-ов.

Запрос:
POST /rest-api
Content-Type: application/x.my-cool-rest-api+json

{
  "resource_id": "id",
  "action": "like"
}


Ответ:
201 CREATED
Location: /rest-api/likes/{like_id}

В чем проблема использовать MessagePack-RPC и его аналоги? Разобрали — передали — собрали. Не хотите разбирать — не разбирайте. Посылайте как есть. Нужны иерархии? Не вопрос.

тут нужно вспомнить, для каких целей изначально создавался HTTP протокол. как по мне — REST покрывает эти цели на 100%. попытки впихнуть в HTTP что-то большее являются костылями изначально. как и все современное web-программирование в принципе…
КО утверждает:
1) Простые вещи должны делаться просто. И их проще несколько раз переделывать целиком, чем обеспечить стабильность-совместимость-и-непротиворечивость-на-века-аминь.
2) Типовых задач — больше 80%. А значит, простые решения будут востребованы всегда. Любая «расширяемая» парадигма, должна уметь деградировать до «hello world», чтобы получить шанс попасть на этот праздник жизни.
3) И тем не менее, взгляд на то, как наилучшим образом решать типовые задачи, имеет каждый суслик в поле. Без этого прогресса не будет, хотя и неразберихи тоже полно.
4) Решение сложных задач — это всегда вызов. Иначе они не назывались бы сложными. Более того: сложная задача сегодняшнего дня может перейти в статус типовой завтра. При решении сложных задач приходится сталкиваться с границами возможностей всего: железа, софта, спецификаций. И иногда приходится изобретать своё, чтобы расширить границы возможного.
5) Автоматизация разработки и её человекоориентированность — это разные цели. Порой, диаметрально противоположные. Для машины удобнее xml, wsdl и прочие строгие вещи. Для человека — html, json (как html, только для ajax). И тут снобизм неуместен: интернет как явление мог бы не состояться, если бы не было простого html и браузеров, очень терпимых к ошибкам в нём. В простых задачах сначала идёт человекоориентированность. И только по мере усложнения и развития приоритет автоматизации усиливается.
6) Интероперабельность, совместимость, интеграция — это задача в третьем измерении, которая решается с учётом первых двух. Если вообще возникает. В огромном числе простых задач — вопросы интероперабельности отсутствуют как класс. Хоть на коне танцуй!

REST недостаточно строг, чтобы его можно было легко и безболезненно использовать для решения сложных задач. Но он позволяет стартануть прямо из Блокнота, после 5 минут видеоурока. В этом его главная фишка.

С другой стороны, запрос на строгость и спецификации есть. А значит будут и спецификации и их достаточно широкая поддержка. Чтобы ещё какое-то подмножество сложных задач стало типовыми.
Сдается мне, что автор начал за здравие, а закончил за упокой. Зачем это сопоставление REST с CRUD? Причем здесь проблема N+1? Сервисы — это фасад, и должны им оставаться. Обслуживающий персонал. Ну надо клиенту получить много связанных данных — ну выстави ты ему агрегирующий ресурс, зачем повторять структуру домена или структуру таблиц в БД? С таким успехом сервисы на основе чего угодно можно сделать эдакой вещью в себе.
Я рад, что эту статью перевели. Я начинал её читать со скеписом, но они меня переубедили.

Люди любят REST за две вещи:
* Сохранять простое простым
* Человекочитаемые URL'ы.

Так давайте следовать этим принципам, и не надо изгаляться с патчем на аптайм сервера для его ребута.
Для меня Swagger оказался открытием и довольно приятным в использовании. Для работы нужно было работать с magento 2 devdocs.magento.com/swagger
Конечно, огорчает клиент под php где среднее качество кода и нет интерфейсов для удобной работы с DI. Еще хотелось бы лучшую поддержку ошибок. И все же плюсов гораздо больше.

Возможно идеальный протокол и должен быть easy to learn, hard to master.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

October 15, 1998

Location

Россия

Employees

5001–10000 человек

Registered

9 August 2008