Odtnhj

I'm currently trying to design a small REST API.

Let's say I have a resource (book) that is composed of multiple other resources (eg. author).

Both resources have separate API's that are deployed in different services (with their own databases).

The author doesn't know a thing about books. However books know their author.

Now I want to support queries like books?author.surname=Poe.

I'm struggling how an implementation could look like that supports this kind of filtering of linked resources.

Since the author doesn't know about books, I can't ask the author api to give me the matching authors and go from here to the related books.
What I could do is ask for every book I have in the DB the author API for that books author and then filter that based on the authors name. But that sounds horribly unperformant.

I guess that nearly every SOA runs into this problem quite early in the design.

I'm asking if there is already a common pattern or best practice that solves this problem?

Your case clearly requires implementation of reliable relation of one-to-many type between these entities (resources). The pattern you're looking for is... relational databases! They have been invented for this particular use case.

This is what I'd suggest:

First, you need to consider and evaluate if this separation and isolation of data is a sound design decision in your particular case, look at the drawbacks and trade-offs you're setting up yourself for. Is there a really good reason to want this data in separate databases?

Consider the following top-of-mind drawbacks:

1. You might end up with under-performing queries;


2. You won't be able to leverage the database indexing and other nice features to your advantage in a future point. This might hinder your ability
   to scale properly in the future


3. You might end up with inconsistent data. For example an author in Books that's now missing from Authors. So you need a way to have reliable constraints (think
   foreign keys) between databases, which even though it might be
   achievable is unneeded complexity


4. You're missing out on the inherent transaction context that a database provides. Should you need that in the future, you'd run into problems.

After having considered the above, if you still believe you have a good reason to have this related data in different databases you can try any of the following options that come to mind (minding that each is a kind of workaround that brings its own drawbacks):

1. Implement a kind of a JOIN between APIs doing as little calls as possible. What I mean is have an Unique ID of Author in Authors resource, Query Authors first with the name and get its unique ID. Then use this id to query Books and get all matching books. Thus you'll only have 2 calls instead of potentially thousands. This solution has constant O(1) instead of O(N) - linear - complexity.




2. Replication of data (but that would kind of defeat the purpose if what you're aiming at with your design is data isolation). This would solve the issue with the query, but you'll have to deal with replications and more administration together.




3. Implement connection between separate databases using dblink or similar feature of the databases that you're using in order to query them as a single database.




4. Use a medium for communication with events between separate micro services but settle for eventual consistency and other drawbacks. See the article here.

Hope this helps!