Comments 153
Код для Angular из apollo:
const CurrentUserForProfile = gql`
query CurrentUserForProfile {
currentUser {
login
avatar_url
}
}
`;
Достаточно JSON-RPC.
Не прочувствовал проблемы.
Никаких стандартов, никаких точных спецификаций.
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.
Но, если пользователи не могут войти в свой аккаунт, то как они «вычищают» их? Т.е. вся ситуация выглядит притянутой за уши.
Этот пример просто показывает, что смешение транспортного уровня и уровня логики приводит к такого рода ошибкам. А вычистить из за такой ошибки пользователей вообще ничего не стоит, потому что где-то на другом серваке стоит другой сервис, который синхронизирует пользователей себе локально, для чего обращается к нашему и если видит, что его уже нет, то удаляет и у себя, например. Это взятый из головы пример, но в целом вероятный. Суть проблемы в том, что вызывающий скприт не понял, что тот 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 и всё восстановить.
Вообще не факт. Допустим, он хранит у себя какую-то информацию, пивязанную к пользователю, например, список его покупок, или сообщений на втором ресурсе, или каких угодно других обрывков информации. И это будет удалено. Откуда восстановится эта информация? (В общем случае, не рассчитывая на резервное копирование или удаление через отметку).
Если под 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 ничего подобного не содержат. И да, решения эти гуглятся за пять минут, и их значительно больше двух.
Мне кажется, Вы просто не понимаете разницу между бинарным и тестовым форматом.
Если вам достаточно RPC и непонятны плюсы REST, не переживайте, пользуйтесь тем, что понимаете. REST, по сути, становится остро актуальным лишь в больших проектах (распределённых и по серверам, и по командам разработчиков всех подсистем), а в малых проектах с командой на 1-3 программиста вы можете даже и не столкнуться со всеми теми ужасами согласования, которые решает REST.
1. REST является platform agnostic способом общения, который требует от платформы только поддержки HTTP. На одном конце может быть С++ сервис, а на другом Javascript, если они оба могут в HTTP, значит у них уже из коробки общая система управления кэшированием, редиректов, повторных запросов, ошибок, аутентификации и прочих вещей которые уже включает себя HTTP.
2. Инфраструктура. Между сервисами общающимися с помощью HTTP/REST, может быть легко построено любое количество инфраструктуры отвечающей за балансировку, проксирование, кэширование, безопасность, логирование, редиректы, нетворкинг и многое другое, без каких либо изменений в коде сервиса. Так как почти все инфраструктурные сервисы/тулзы поддерживают HTTP, a REST по своей природе опирается на все возможности HTTP, а не просто использует его как транспорт.
3. HATEOAS
PS: я не сторонник REST. Но, если мне нужно будет работать с legacy инфраструктурой, я предпочту REST.
Поэтому считается что в случае идеального REST правильно настроить кеши проще.
1 и 2 по сути применимы к чему угодно, использующему HTTP как транспорт.
Обычно, чтобы понять назначение RPC запроса, нужно научит ифоаструктуру хотя бы на базовом уровне понимать тело этих запросов. Возьмём самое простое — кэширование. В http/rest у идемпотентных запросов есть явные характеристики, и большенство из них можно смело кэшировать. У RPC запросов, не ясно, есть ли у метода side effects и является ли он безопасным для кэширования. В этой ветке хорошо заметили — RPC почти не оставляет на уровне HTTP подсказок о себе, для него, это всего лишь транспорт.
Ну, это от реализации зависит. Хотя, да, люди бросаются в крайности обычно: или стараются натянуть предметную область на семантику HTTP чуть более чем полностью, изобретая, например, несуществующие ресурсы или подресурсы, для обхода сильного ограничения на количество доступных действий, или вообще игнорируют возможности, предоставляемые HTTP, заботясь только об обходе нежелательных им особенностях, типа кэширования.
или на новичков вроде GraphQL и gRPC для публичных API…Только для публичных API?
А вообще — это частный случай (разных выдач для мобилок и десктопов обычно не так много). Иногда можно отдать избыточную информацию для мобилки. Иногда можно переписать сервис, чтобы потом десктоп дозабрал недостающие данные. Можно применить что-то вроде OData или GraphQL (но не ко всей системе, а только для этого сервиса).
Новый супер-важный клиент (НСВК):… ну и вот примеры запросов ответов которые вы должны нам слать (приаттачивает какие-то непонятные файлы со строками, похожими на команды модема)
Я: че это за Х?
НСВК: ну как же, это ж EDI, пфф…
Я: послушайте, мы поддерживаем SOAP, REST, JSONRPC…
НСВК: нет, мы работаем только с EDI
Я: вы хотите что бы мы реализовали у себя на стороне поддержку этого ммм… протокола? Посоветуйте хотя бы какие-то оббертки совместимые (по опыту с SOAP знаю что не каждый клиент понимает какждый сервер и т.п.), я вот тут нашел на питоне bots, но он страшный какой-то (там зачем-то ему нужен сервер на джанго чтоб конвертить хмл в EDI)…
НСВК: (приаттачивает непонятных людей в СС с мейлами из OpenText)
Люди с мейлами из OpenText: здравствуйте, мы компания OpenText, крупнейший интегратор EDI, приходите на наше демо
Демо:
Мы многомиллиардная корпорация (действительно, слайды с ревеню зашкаливающие), мы нарисовали схему, вот тут вы, тут мы, а тут ваш НСВК.
Заманчивый слайд с ценами, всего порядка нескольких десятков К долларов с лица (включает стажировку и курсы специалиста по настройке конвертора ХМЛ в EDI).
Занавес.
А вы говорите REST или JSON-RPC…
В муле есть коннектор. В принципе, он и закрывает у нас все вопросы по теме.
На самом деле, если уж по-честному, обленились вы там, ребята.
Все вам на блюдечке подавай.
Стандарт старый, спецификацию в руки, и вперед.
Ничего там сверхъестественного нет.
Ну а курсы и т.д. — это бонус. Хорошо, когда есть.
Не, ради двух АПИ городить поддержку EDI, даже ради такого важного клиента, не знаю…
Не нашлось видимо пока желающих — жадные все :-).
bots этот питоновский, с админкой на джанге…
Представляете, если б для интеграции по JSON-RPC или REST вам на полном серьезе предлагалось поднять у себя особый сервер, пойти в админку, нарисовать там какие-то схемы, соединить все правильно, написать кучу текста мета-описания, все это для того чтобы сгенерить ХМЛ, который потом сможет прочитать ваш софт! В топку весь этот EDI
Представляете, если б для интеграции по JSON-RPC или REST вам на полном серьезе предлагалось поднять у себя особый сервер, пойти в админку, нарисовать там какие-то схемы, соединить все правильно, написать кучу текста мета-описания, все это для того чтобы сгенерить ХМЛ, который потом сможет прочитать ваш софт! В топку весь этот EDI
Вообще-то именно так и работают интеграционные шины (ESB). И в топку нужно выкинуть именно их, а не 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
Вы какой вариант предпочтете для интеграции?
Для интеграции с уже готовой системой я предпочту тот формат, который той самой системой поддерживается :-)
Да, то что вы привели — выглядит некрасиво. Но я не вижу технических сложностей ни в том чтобы такое сообщение сформировать, ни в том чтобы его распарсить.
Вы какой вариант предпочтете для интеграции?
Тот, который нужен клиенту и за который платят деньги.
А если клиенту подойдут оба и заплатят одинаково?
Обсуждается именно «я хочу так, но клиент-бяка не согласен, и плевать, что у него уже тонны софта под этот стандарт написаны».
Так-то, конечно, можно выбрать то, для чего есть готовые библиотеки и для чего решение можно слепить быстро.
Наша жизнь слишком коротка, чтобы плодить велосипеды на стандарты 60-х годов в 2017, как-то так…
Если у клиента тонны софта под EDI, пусть удосужиться написать оббертку человеческую
Щито? Клиент нанимает разработчиков, и он им еще должен писать обертки? Потому что они хотят работать по системе тяп-ляп и готово?
Наша жизнь слишком коротка, чтобы плодить велосипеды на стандарты 60-х годов в 2017, как-то так…
Так в чем проблема? Придет другой подрядчик и напишет.
А пример этого самого EDI? Ну и потом, а какой-нибудь integration engine использовать не пытались, нет, оно там возможно уже сделано.
Я: вы хотите что бы мы реализовали у себя на стороне поддержку этого ммм… протокола? Посоветуйте хотя бы какие-то оббертки совместимые
Херакс, херакс и в продакшн не получилось. Верно сказали выше — обленились вы, ребята.
Я не согласен, что по щучьему велению клиента, или за деньги компании, нужно кидаться реализовывать решения любой степени маразматичности. Понятно, что можно прочитать их мануал на 300 страниц, постичь все аббревиатуры и посчитать звездочки правильно и за пару недель наговнокодить энкодеры\декодеры, но я просто не буду этого делать.
Более того — OpenText не заинтересован в таком исходе, их цель — продать своих ребят, свой софт и себя, поэтому никакого содейсвтия не будет.
А мне потом еще месяцами разгребать баги и искать где звездочка пропущена, извините!
Схема, конечно гениальная! Все понимают что EDI — нездоровая хрень и атавизм в 2017, но мы вас всех готовы спасти, только заплатите.
Схема, конечно гениальная! Все понимают что EDI — нездоровая хрень и атавизм в 2017, но мы вас всех готовы спасти, только заплатите.
Есть программисты, которые хотят переписать все с нуля на модном стеке, а есть бизнес, которому лучше держать таких специалистов от себя подальше. Нет смысла сливать уже оплаченный софт, часы разработки в унитаз, из-за того, что кто-то весь такой модный и в белом пальто хочет иметь красивую строчку с модными технологиями в резюме. Здесь устремления конкретного человека-разработчика и бизнеса не пересекаются.
Вы не хотите даже при адекватной оплате написать обертку, которые и вы и другие смогут использовать в будущем?
Я всю жизнь сидел на SOAP только потому, что не очень удобно писать десериализаторы на клиенте под крупные JSON/XML данные, а тут такая конфетка, что аж руки зачесались применить её в каком-нибудь API.
Дальше уже обычный REST с PUT/PATH/POST/GET/OPT… etc.
По Swagger / OpenAPI описанию можно генерировать клиента (например), плюс многие библиотеки сразу дают красивый UI с примерами запросов, от чего клиенты обычно в восторге.
Этот OpenAPI показал себя в полной мере после появления версии 3. Поддержка версии 2 была уничтожена в Eclipse — поддерживает его одна компания и их не интересует ничего кроме их же SwaggerHub. Фактически OpenAPI/Swagger — проект одной компании. Вторая версия вообще не позволяла описать некоторые важные моменты, третья позволяет, но не реализована для некоторых языков. Дурацкая ситуация — наработано всё под swagger2, а Eclipse ставит пакет для несовместимого swagger3 :) И по сложности от SOAP ушло всё это недалеко.
Поэтому мы забили на REST и перешли на gRPC. Стало гораздо удобнее и однозначнее.
Мы приспособили его к web с помощью grpc-gateway. Да, оно конвертит в тот же пресловутый json, но на стороне сервиса мы все еще пишем api на gRPC и не пытаемся заигрывать с REST. Сейчас также изучаем возможность работы с нативным gRPC на клиенте.
CLI действительно менее удобный. Однако, по сравнению с сваггером (OpenAPI) тут есть вменяемый красивый DSL.
REST, на мой взгляд — достаточно ущербный стиль взаимодействия, который добавляет больше проблем и неоднозначностей, чем решает. Далеко не любые бизнес-процессы можно выразить с помощью REST: если у вас что-то сложнее чем CRUD, то начинаются проблемы. Ведь в REST мы говорим существительными и оперируем ресурсами. В классическом RPC — глаголами. Бизнес-процессы удобнее выражать глаголами.
Что касается gRPC: у нас много сервисов на разных ЯП и нам удобно:
- Описывать API одинаково и на нормальном языке.
- Генерировать из него клиенты и серверы. Весь тулинг официальный и активно поддерживается. Сами 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 и HTTP.
И уж тем более невозможно уберечься от падения. А обвинять в «криворукости» — это подход прыщавой школоты
Представьте, что у вас есть некий охраняемый объект и есть датчик открытия двери. Пусть он нормально разомкнутый, а при открывании замыкает цепь. Реализуется просто — появилось напряжение на вводе — сигнал тревоги. И все хорошо, но если провод поврежден или просто откушен — система не сработает. И можно сколько угодно топать ногами, гневно восклицая, что монтажники — дураки, проложили кабель в видном месте и вообще что он не заминирован и не надо, мол, с больной головы на здоровую перекладывать. Сделать это идеально не получится и все равно система даст сбой рано или поздно. И эта возможность отказа заложена в самой системе, это и есть «паршивое решение».
И протокол сам следит за корректностью данных, чтобы они соответствовали шаблону. Полный ordnung. Опять же автоматическая генерация кода сервисов на основе этой wsdl
А XML — да, мне кажется более надежным чем JSON. Поддержка везде, в самых экзотических системах. Нативная поддержка в Java. Для сравнения, JSON схема 4 — все еще в драфте, а библиотека для Java — сторонняя опенсоурсная, распавшаяся в свое время на два не полностью совместимых бранча.
SOUP это операции, порядок, секюрность, транзакции, сложность,
REST — простота, работа с ресурсами, веб,
RPC — завязка на одну технология/язык + производительность.
Message query/RabbiteMQ и т.п. — завязка на одну MQ систему, локальность, надежность и производительность.
У каждой технологии своя ниша.
Нативная поддержка в Java. Для сравнения, JSON схема 4 — все еще в драфте, а библиотека для Java — сторонняя опенсоурсная, распавшаяся в свое время на два не полностью совместимых бранча.
Не одна их много, есть нативная поддержка json в JEE. Да и какая разница, если все равно все пользуются? Как будто последную версию xml java может не поддерживать.
И протокол сам следит за корректностью данных, чтобы они соответствовали шаблону.
Не, не следит. Можно иметь 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ы использовать, зачем гвозди микроскопом забивать…
А можно сделать
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, правда? :-)
Интересно что вернет GET "/rest-api" :)
1) Простые вещи должны делаться просто. И их проще несколько раз переделывать целиком, чем обеспечить стабильность-совместимость-и-непротиворечивость-на-века-аминь.
2) Типовых задач — больше 80%. А значит, простые решения будут востребованы всегда. Любая «расширяемая» парадигма, должна уметь деградировать до «hello world», чтобы получить шанс попасть на этот праздник жизни.
3) И тем не менее, взгляд на то, как наилучшим образом решать типовые задачи, имеет каждый суслик в поле. Без этого прогресса не будет, хотя и неразберихи тоже полно.
4) Решение сложных задач — это всегда вызов. Иначе они не назывались бы сложными. Более того: сложная задача сегодняшнего дня может перейти в статус типовой завтра. При решении сложных задач приходится сталкиваться с границами возможностей всего: железа, софта, спецификаций. И иногда приходится изобретать своё, чтобы расширить границы возможного.
5) Автоматизация разработки и её человекоориентированность — это разные цели. Порой, диаметрально противоположные. Для машины удобнее xml, wsdl и прочие строгие вещи. Для человека — html, json (как html, только для ajax). И тут снобизм неуместен: интернет как явление мог бы не состояться, если бы не было простого html и браузеров, очень терпимых к ошибкам в нём. В простых задачах сначала идёт человекоориентированность. И только по мере усложнения и развития приоритет автоматизации усиливается.
6) Интероперабельность, совместимость, интеграция — это задача в третьем измерении, которая решается с учётом первых двух. Если вообще возникает. В огромном числе простых задач — вопросы интероперабельности отсутствуют как класс. Хоть на коне танцуй!
REST недостаточно строг, чтобы его можно было легко и безболезненно использовать для решения сложных задач. Но он позволяет стартануть прямо из Блокнота, после 5 минут видеоурока. В этом его главная фишка.
С другой стороны, запрос на строгость и спецификации есть. А значит будут и спецификации и их достаточно широкая поддержка. Чтобы ещё какое-то подмножество сложных задач стало типовыми.
Люди любят REST за две вещи:
* Сохранять простое простым
* Человекочитаемые URL'ы.
Так давайте следовать этим принципам, и не надо изгаляться с патчем на аптайм сервера для его ребута.
Конечно, огорчает клиент под php где среднее качество кода и нет интерфейсов для удобной работы с DI. Еще хотелось бы лучшую поддержку ошибок. И все же плюсов гораздо больше.
Возможно идеальный протокол и должен быть easy to learn, hard to master.
REST — это новый SOAP