Swagger-codegen: Add AMQP transport
This is just a sort of a crazy idea of using Swagger Spec for REST over AMQP protocol instead of HTTP. I do understand that this will require a huge amount of work, but I would love to at least have a discussion on this now. Who knows, maybe somebody will find it so useful, so they implement it (maybe even myself).
Extra keywords for search: RabbitMQ, ActiveMQ.
Related discussions:
frol
All 7 comments
@frol we love crazy ideas :)
Just to be clear your backend is still RESTful and transport is over AMQP instead of HTTP, right ?
And which language are you targeting to begin with?
wing328
on 30 Mar 2016
Just to be clear your backend is still RESTful and transport is over AMQP instead of HTTP, right ?
Correct.
And which language are you targeting to begin with?
I'm mostly interested in Python as a server and a client language now. However, Swagger-UI support is also very important from my point of view, so JS client might be even more important than Python client.
frol
on 30 Mar 2016
Technically that's possible. For Java, we already support a few HTTP libraries - Jersey1.x, Jersey2.x, Retrofit1.x, Retrofit2.x, Feign, okhttp, etc based on the design that ApiClient is swappable.
For Python, you can try to do the same thing by implementing an ApiClient that talks AMQP and use -l to specify which ApiClient/library to use when generating the Python API client.
wing328
on 30 Mar 2016
While usage of AMQP may sound like not so compex task to implement, AMQP is quite different from HTTP. The biggest obsticle is that AMQP is unidirectional, so you can either send messages, or receive messages. Having this in mind, you cannot expect any "response" from AMQP by design (though, you can implement a workaround, yet it is generaly a bad idea for AMQP flow design). Still, there are use -cases for AMQP-style "requests": delayed creation/deletion/execution, which are often ends up with HTTP 204/No contents response.
frol
on 30 Mar 2016
@frol if you don't mind, can you share a bit more on why your team decided to use REST over AMQP instead of HTTP?
Personally I don't see a lot of tools built around REST over AMQP
wing328
on 30 Mar 2016
Sure! First of all, we love Swagger, isn't this enough? :)
Second, while most of the people implement RPC over AMQP, I don't see much difference in REST and RPC over AMQP because both are limited by the fact that "request-response"-style is not what AMQP is made for. From my point of view, the difference between REST and RPC over AMQP turns out to be in the terminology. If we implement either REST or RPC without Swagger, we are bound by contract-style interactions, which is failure-prone. What I love about Swagger, it is the idea of having a simple config file, which can be used on a client side enforcing communication interfaces, hiding implementation details, and freedom of choice of the client/server languages (for example, there are projects like Celery in Python world, which implements RPC over AMQP and enforces the communication interfaces by having all code written in Python and available to clients (you need to make an extra work to decouple the interfaces from the workers, so you, at least, don't need to share the whole server-side code to the clients)).
frol
on 30 Mar 2016
What about doing something like these guys are doing https://github.com/asyncapi/asyncapi
by the way, they took as reference the OpenAPI Initiative
rmelian
on 22 Oct 2018
Related issues
edwinevans
路
3Comments
NabiKAZ
路
3Comments
vlgunarathne
路
3Comments
dylan-colaco
路
3Comments
justwy
路
3Comments
Most helpful comment
Sure! First of all, we love Swagger, isn't this enough? :)
Second, while most of the people implement RPC over AMQP, I don't see much difference in REST and RPC over AMQP because both are limited by the fact that "request-response"-style is not what AMQP is made for. From my point of view, the difference between REST and RPC over AMQP turns out to be in the terminology. If we implement either REST or RPC without Swagger, we are bound by contract-style interactions, which is failure-prone. What I love about Swagger, it is the idea of having a simple config file, which can be used on a client side enforcing communication interfaces, hiding implementation details, and freedom of choice of the client/server languages (for example, there are projects like Celery in Python world, which implements RPC over AMQP and enforces the communication interfaces by having all code written in Python and available to clients (you need to make an extra work to decouple the interfaces from the workers, so you, at least, don't need to share the whole server-side code to the clients)).