I really like the Nameko/RabbitHQ microservice architecture and I’ve written a number of services that do stuff for me. RESTful just looks harder. However, if you’re in a bit of a fix I can see that RESTful might be useful (eg screen-scaping a webpage). RPC seems more scalable, because you can just spin up more. Not sure it’s so easy with webservers. However, when I research pros and cons of each, I get a bit confused. It seems to me that RPC/RabbitMQ is newer than REST, but Google says REST is newer What’s the real position? Maybe I’m not using the right terminology.
REST and RPC are just two different ways of building an API. They serve different purposes, and one of the nice things about Nameko is that you’re free to mix and match within a single service.
REST is a structured way of building an API that uses HTTP. To be truly RESTful there are very specific things you do and most HTTP APIs that call themselves RESTful aren’t really, but that is an aside.
RPC just means Remote Procedure Call and there are tons of different ways to implement it. Nameko’s built-in RPC uses AMQP as the protocol (and RabbitMQ as the broker) but there are many alternative implementations.
The main advantage of Nameko’s RPC is that it’s very light weight – from a client perspective it looks like a normal Python method. The disadvantages are that it requires a RabbitMQ broker and only works within a local environment (RabbitMQ does not do well over wide-area networks).
HTTP “REST” APIs are everywhere of course and they’re the natural choice for an API that you want to expose to the internet.
Thanks for that. So REST works well over the internet. So I call a whole load of apis "REST"ful, as long as they use get put etc, sometimes even if they break the rules. What class of apis is Nameko a member of? Can restful apis do pub-sub, for instance? When I google apis, I find that RPC is alder than rest, but that is not what I experience here. Formula 1, for instance has just migrated from REST to RPC. If RPC was older that would be a retrograde step.
You can build RESTful (and RESTish) APIs in Nameko, using the built-in @http entrypoint.
You can build AMQP-RPC interfaces, using the built-in @rpc entrypoint.
You can build pub-sub interfaces, using the built-in events and messaging extensions.
You can build slack bots, using the extensions at GitHub - iky/nameko-slack: Nameko extension for interaction with Slack APIs
You can build gRPC interfaces, using the extensions at GitHub - nameko/nameko-grpc: GRPC Extensions for Nameko
You can build any kind of interface you like as long as you write the extension
