CODEWITHSUNDEEP
restmicroservices
ibexit
ibexit

Reputation: 3667

Microservices/REST - How to store references to resources in other service

Assuming a resource X(http://example.com/a/foo/7) from rest-service A needs to hold a reference to a second resource Y(http://example.com/b/bar/1) from rest-service B.

How would one persist the reference?

Currently I'm storing the whole URI (as a string) of Y in the persistence layer of service A. Is this a common/valid approach? It seems wrong to me to extract the id(1) out of Y's URI as I would implement assumptions about the URI structure of service B in service A. Is this correct?

How do you solve this problem?

Thx!

Upvotes: 1

Views: 2015

Answers (2)

techagrammer
techagrammer

Reputation: 1306

Lets discuss it with some actual business domain , then the answers will make sense.

So first example:

X represents Order Entity in Amazon Order Service, Y represent Customer in Customer Service.

Now while fetching the order from Amazon from Order Service, you also want to show some basic customer detail and link to customer Object to go to Customer Detail Page.

In this case what I would do is while creating the order copy some basic attributes of the customer in Order Entity (customerName , customerArea).

Also store customerId, customerType. And as the API for fetching customer is Public and also exposed to various internal services, Order Service will do a Service discovery and create URL and call. In these cases generally customer service will not stop supporting the old way (even if they are building a new one).

So storing just the id is a solution.

CASE 2:

Amazon Order Entity wants to store delivery details and delivery partner is some third party entity like DHL , then if DHL provides a URL to fetch the delivery updates to the order, in those cases I will just store the URL.

Generally I will prefer to store id and service type and some basic details to create a good customer experience and also avoid hitting one extra service api for getting the basic detail like customer name.

Storing direct URL makes sense when its a third party URL.

Also if you can give certain example of your business case like this, we can discuss better

Upvotes: 1

Anunay
Anunay

Reputation: 1893

IMO references should be stored as is. How you get the actual data from reference should not be part of the data but the logic which may change from time to time. I will store them as reference of external reference (just to paint the picture that reference is out side our service) and coupled it with a logic to query the data.

URL is very volatile and may change. As a rule of thumb you should never keep urls in you database and should rely on service discovery to identify where the service is even if its within you own infra.

Its not an assumption, its a contract, which may changes and if it does, your service will be dependent service and has to make due changes

Also by your logic, even if you keep url, response to it is still a contract that both of you adhere to.

Upvotes: 0

Related Questions