REST APIs seem to have taken over dev mindshare. I believe part of that is how well they map to already-understood concepts like databases. Databas...
For further actions, you may consider blocking this person and/or reporting abuse
Your article is just chewing the CUD! What about the Read aspect? I find this a lot harder to represent with use cases because you end up with the API getting bogged down with presentation detail, or being too general and providing too much information for sensible bandwidth. Do you have any tips on getting that part of the API as succinct?
This is a thoughtful point. It is true that Read concerns can be drastically different from Write concerns. For example, full text search may be very important for reads, but is excess baggage when processing use cases (writes). No style of API is going to solve this problem for you, since it has more to do with the underlying data structures. But message-based does have a couple of tricks.
For example,
SearchCourses { Search: 'foo', Page: 1, PageSize: 20 }might return multiple rows with only a few columns, just enough for displaying in a list. WhereasGetCourse { CourseId: 123 }might return the full details for exactly one course. Another oneGetCourseDashboard {}might return several sets of statistical data. For APIs which service applications, I tend to tailor every (query) message and its returned data to the specific screen that uses it.I can also tell you what I do to solve the data structure problem: I no longer try to use a one-size-fits-all data model. I create multiple models of the same data to suit different purposes. One of the models needs to be authoritative (probably the write model), but others (probably read models) can be projected off of that one. For example, shipping your data to Elastic Search for indexing. Another example is an executive summary report (which is just an aggregated version of the data). These are obvious cases, but also think about each of the queries I mentioned in the paragraph above being backed by their own tables.
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.
I think that this is quite like GraphQL
Thanks for the comment. I suppose GraphQL could be a subset of a message-based API. My main point was that messages can help you represent business use cases at the API level instead of just data.
Totally, this is quite useful compared to the conventional way. Thanks for the good read.
Quite welcome! :)