Комментарии 28
И очень хотелось бы узнать в каком именно месте развитие слабее.
Вот вам пример: вы присылаете в сервис несколько бинарных блобов вместе с их путями, степень и тип сжатия.
Вам надо запаковать эти блобы под их путями в архиве и выдать клиенту блоб представляющий архив.
Как бы вы это сделали с помощью вашего RAML и REST?
Под более слабым развитием я подразумеваю количество тулзов и возможности ими предоставляемыми. И степени их adoption
Но непонятно, какое это имеет значение в контексте статьи для широкой аудитории.
Ну вот: тулзы это уже конкретика, их как раз и можно было бы сравнить.
А по поводу «enterprise» или «cloud» у меня возникает только один единственный вопрос: что означают эти термины в вашем понимании и в чём между ними отличие?
Вот, к примеру, сервисы Amadeus (глобальной системы бронирования авиабилетов) это «enterprise» или «cloud»?
А если сервера, то там нас ждет еще XSD схема. На такое даже после WCF SOAP без слез не взглянешь.
Достаточно проаннотировать интерфейс и импелементировать для сервера.
А на клиенте получить прокси, для того же интерфейса.
Для этого даже ни одной библиотеки не надо подключать — всё доступно в голой JDK с версии 6. Можно запускать серверную часть без всякого сервера и Spring Boot — ов.
Вот это я понимаю: настоящий микросервис
Да не сказал бы, что всё примитивно. Одни статусы ответа чего стоят. Всегда поиск компромиссов
Или передача параметров запроса, тоже мутный вопрос: делать таки гигантский get, или всё-таки post с телом, в который положить все параметры запроса
В rest очень много тонких мест, которые реализуются по разному в разных командах
Иногда возникают ситуации, когда надо сидеть и читать сам WSDL, а это тоже занятие на любителя.
Опять же, были ситуации, когда SOAP сервис не мог дать свыше 50 RPS в сокете. И разработчики сервиса в принципе не понимали, с чем связано это ограничение. Оно от них скрыто 50 уровнями абстракции.
Плюс имплементация на Java и у MS могут быть небольшие разночтения.
А если в wsdl добавят «Any», то концов не найдешь.
Гарантированно куча приключений.
Плюс для работы нужно из wsdl/xsd генерировать классы, с кучей аннотаций.
Хорошо если автогенерированные классы сразу подойдут.
Если нет, то надо еще плясать с Jaxb-bindings.
В этом плане JSON (REST), это то что надо.
Все просто.
POJO не нужны аннотации в 99% случаев.
Есть удобный серриализатор/дессериализатор Gson.
Спасибо.
Я уже вдоволь наработался с SOAP сервисами. :-)
Основываясь на документации с сайта swagger.io(раз, два), мы воспринимали Swagger как старое название OAS. Релиз третьей версии — это OAS3, релиз второй версии — это Swagger 2, но OAS3 — это развитие swagger2. То есть формально Swagger 3 не существует, равно как и OAS2. Но это казалось усложнением в статье, поэтому мы их прировняли. Ты ведь на это ссылаешься? Или есть какие-то отдельные ветки эволюции и Swagger 2 породил не только OAS3, но и swagger 3?
Для генерации необходимого документа использую io.swagger.core.v3:swagger-maven-plugin, который понимает jakarta.ws.rs:jakarta.ws.rs-api аннотации на REST интерфейсах с помощью io.swagger.core.v3:swagger-jaxrs2
При этом только Swagger 2 имеет хорошую поддержку инструментария OpenSource. RAML – очень гибкий… и сложный, а Swagger 3 слабо поддерживаются коммьюнити, так что вам придется пользоваться инструментами собственной разработки или коммерческими решениями, которые, как правило, стоят весьма дорого.
На мой взгляд, наоборот, community очень активно поддерживает и расширяет как AOS 3, так и open-source проекты под неё.
Например, для генерации клиентского кода на C# или TypeScript есть расширение для Visual Studio 2017/2019 — Unchase OpenAPI Connected Service, которое позволяет легко генерировать proxy-классы для взаимодействия с OAS и Swagger 2 с настройкой различных параметров (аналогично NSwagStudio). Достаточно иметь (сгенерировать или создать вручную, в т.ч. с помощью специализированных online-редакторов) endpoint URI (URL, json- или yaml-файл спецификации).
Как им пользоваться можно прочитать здесь: How to generate C# or TypeScript client code for OpenAPI (Swagger) specification.
зашёл в статью почитать как люди готовят REST и наверное не нашёл то, чего искал – понимания почему его до сих пор горячо любят и активно используют…
у GraphQL интроспекция схемы – часть стандарта, и вопрос как его документировать пожалуй не особо актуален, JSON-RPC простой как валенок и для небольших сервисов его можно описать в одном md-файле. оба имеют стандартные механизмы для пушей через веб-сокеты.
у REST-а же вечные споры какой код ошибки правильно послать на ту или иную ошибку. под знаменем с {"success":false} марширует толпа вордпрессеров. а как правильно засадить фильтры и сортировки в выборки. а коммент к посту – это /comment/:id или /post/:post_id/comments/:comment_id – let the battle begin. и снова отсутствие стандарта на пуши через веб-сокеты…
я наверное что-то упустил, но с REST в проектах я постоянно вижу какую-то сборную солянку и кустарщину. может мне просто не везёт?… или просто я смотрю на REST с клиентской стороны, а для внутреннего общения микросервисов вот это всё – вообще не проблема?…
Отвечая же на Ваше сравнение с GraphQL — как архитектор вы всегда в поисках компромисса: жесткий стандарт не всегда уместно ограничивает и порождает уродливые конструкции, гибкое и более высокоуровневое описание дает возможность как написать очень хорошо, так и написать очень плохо…
Так все-таки RAML или OAS (Swagger)?