CODEWITHSUNDEEP
spring-bootrestdesign-patternsmicroservicesopenapi-generator
Phate
Phate

Reputation: 6622

Nested resources and microservices: how to avoid monoliths?

I want to retrieve the address details of a person.

According to the REST specification I would have to have the following path:

GET /person/<person id>/address/<address id>

Now, suppose I want to retrieve the electronic addresses, I would have:

GET /person/<person id>/address/<address id>/electronic/<elec id>

And so on. While REST-wise it is fine, it can lead to a monolithic approach as the openapi generator (but also a person implementing it) would create one lone microservice handling several kind of data.

What could be another way to deal with this scenario? I was thinking of:

1-reversing the logic

GET /addresses/<person id>/<address id>
GET /electronicAddresses/<person id>/<address id>/<electronic address>

2- use headers/query string parameters and leave to single services

GET /addresses/<address id>?person_id=
GET /electronicAddress/<elec id>?person_id

Can I have some practical directions? I feel that inner resource approach would explode in the end...

Upvotes: 0

Views: 543

Answers (1)

ish
ish

Reputation: 171

If I understood you correctly, you want to decomposite your API and map it to a microservice architecture, like with the case with address and person.

If so, consider address and person how something independent, so there will be two services: Person service and Address service. Which will have next APIs:

GET /persons/{person_id}
GET /addresses/{address_id}

The question now, how to get the address of some person, since all address API doesn't have any person related request parameters. The answer is: make two API calls.

So, with the first request client retrieves person data by person_id which should contain some reference to address entity, like: address_id. With the second request now, a client can retrieve a person address by address_id parsed from personal data.

Upvotes: 1

Related Questions