Hi, this is an interesting post, but I am afraid this approach doesn't scale very well. In a simple REST approach every resource is isolated giving the developers the freedom to combine these resources in many different ways where this message approach seems to look very specific.
So I think using a REST api is more useful for big apps that would let developers use their granular resources in every way they want, while this message approach seems to fit to a very personal api, thus forcing other developers to only use the messages available.
That's why I think the approach doesn't scale well, because it's hard to create messages for every use case a developer might use.
I see where you are coming from, but this method doesn't have any more difficulty scaling compared to REST-based. (How you describe scaling, I think you are referring to Isolation.) It is not a function of how you package the requests and responses, but of how well the system boundaries are drawn. Message-based (especially for queries) can be divided up by responsibility area just like REST.
For writes, it does not make for a very developer-friendly application for things which logically belong together to be split up into multiple REST endpoints just because they are separate entities. It turns the API into a leaky abstraction of the underlying data model. It puts the responsibility on the client of knowing exactly which entities should be updated, in what way/order, and how to rollback if one fails. This is not a good experience for the consumer of the API. And they may not do it correctly.
Things which are logically separate can be on different endpoints (or nodes) in either REST or message-based. E.g. for message-based /api/sales/ChangePricing and /api/accounting/ApplyPayment.
Re: forcing developers to only use available messages.
Even with REST, you have to expose the API contract somewhere (i.e. documentation). REST does not handle requests until they are wired up to some handling code. It is no harder to create messages for every use case than it is to create REST endpoints for every use case. And using message-based doesn't mean you have to throw away everything (orthogonal but) typically associated with REST, like content negotiation and hypermedia. Use whichever combinations suit your problems best.
Hi, this is an interesting post, but I am afraid this approach doesn't scale very well. In a simple REST approach every resource is isolated giving the developers the freedom to combine these resources in many different ways where this message approach seems to look very specific.
So I think using a REST api is more useful for big apps that would let developers use their granular resources in every way they want, while this message approach seems to fit to a very personal api, thus forcing other developers to only use the messages available.
That's why I think the approach doesn't scale well, because it's hard to create messages for every use case a developer might use.
I see where you are coming from, but this method doesn't have any more difficulty scaling compared to REST-based. (How you describe scaling, I think you are referring to Isolation.) It is not a function of how you package the requests and responses, but of how well the system boundaries are drawn. Message-based (especially for queries) can be divided up by responsibility area just like REST.
For writes, it does not make for a very developer-friendly application for things which logically belong together to be split up into multiple REST endpoints just because they are separate entities. It turns the API into a leaky abstraction of the underlying data model. It puts the responsibility on the client of knowing exactly which entities should be updated, in what way/order, and how to rollback if one fails. This is not a good experience for the consumer of the API. And they may not do it correctly.
Things which are logically separate can be on different endpoints (or nodes) in either REST or message-based. E.g. for message-based
/api/sales/ChangePricingand/api/accounting/ApplyPayment.Re: forcing developers to only use available messages.
Even with REST, you have to expose the API contract somewhere (i.e. documentation). REST does not handle requests until they are wired up to some handling code. It is no harder to create messages for every use case than it is to create REST endpoints for every use case. And using message-based doesn't mean you have to throw away everything (orthogonal but) typically associated with REST, like content negotiation and hypermedia. Use whichever combinations suit your problems best.
Thanks for the reply.