Microservices/REST - How to store references to resources in other service
up vote
1
down vote
favorite
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!
rest microservices
asked Nov 7 at 20:47
ibexit
656313
add a comment |
up vote
1
down vote
favorite
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!
rest microservices
asked Nov 7 at 20:47
ibexit
656313
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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!
rest microservices
asked Nov 7 at 20:47
ibexit
656313
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!
rest microservices
rest microservices
asked Nov 7 at 20:47
ibexit
656313
asked Nov 7 at 20:47
ibexit
656313
edited Nov 7 at 21:07
asked Nov 7 at 20:47
ibexit
656313
asked Nov 7 at 20:47
ibexit
656313
asked Nov 7 at 20:47
ibexit
656313
656313
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
1
down vote
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
answered Nov 8 at 11:59
techagrammer
678414
thank you @techagrammer for your answer! CASE2 is pretty clear -I#m with you in this case. But in the first case, you're saying, that i should store the customerId, not the URI. But what if the service is not exposing this internals in the response? Then, imo, the URI is the only availabe unique resource identifier. But even if there is such data, in order to rebuild the URI, I´ll need to know how to build, based on a uri template.
– ibexit
Nov 8 at 19:58
@ibexit there is a certain assumption in case 1 that team know some internals of other service (how to discover the service and call the API's) . As Order and Customer Service are being developed on some core principles which the entire organization will abide, which will help them to speed up the development. If you framework like Lagom and other microservice framework they do these service discovery and all out of the box. Also imo building services such that one dosen't know a thing about the other in the same org is not the good idea as that will have larger overheads
– techagrammer
Nov 13 at 7:39
Hey @techagrammer, happy to see you back here. Just to make it more specific. Let's say service A is CategoryService, B is BookService. We need to categorize boolks. One book to store in a category is looking like this:GET http://example.com/books/123456 { “title“: “lorem ipsum“ }. How you would store the reference to the book in the CategoryService?
– ibexit
Nov 13 at 7:48
@ibexit in this assuming category have list of books and book can be in multiple categories, also assuming category service is not a very very generic service like tag in which you can tag anything, when I add a book in a category I will call API "example.com/category/1/addBook" data is {"bookId":"book-1"}. Now when category service store this it will query the book service and fetch the book details using the BookService Interface in Category Service by calling a function getBook - (which might internally hit it via REST or use GRPC ) and save {bookId : book-1 , title : book-title}.
– techagrammer
Nov 13 at 9:20
Got your point. But have you seen, there is no bookId in the books response?
– ibexit
Nov 13 at 9:39
add a comment |
up vote
0
down vote
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.
answered Nov 8 at 6:03
Anunay
904617
Thank you very mutch for your reply. I totally agree that a URL and response may change. I see the URI not (only) as a reference or way to get the entity, but manly as a Uniform Resource Idenifier. Of course, this URI don't have to be the URI of a particular service instance, but the URI based on a API gateway. If the URI changes for the very same entity, there should be permament redirects on the old URI. Now we'll be able to update the stored URI (if we want).The same applies for response changes - the old representation should be still there, available as a projection of the new format. ???
– ibexit
Nov 8 at 19:47
Its not just about them changing. URI are means to get data, and there could be other means as well. Rest endpoints just gives you an address to knock on and ask for data for given reference, tomorrow you may want to other means of these communication. IMO they should be separate. Also if you are in control of how changes should propagate in services you can take a call, but if you are not, I would rather not want to go through and update 100's of entries just because service Y or api gateway decided to rename the endpoints.final call is yours, if you think pros outweighs the cons, so be it.
– Anunay
Nov 9 at 5:24
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
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
answered Nov 8 at 11:59
techagrammer
678414
thank you @techagrammer for your answer! CASE2 is pretty clear -I#m with you in this case. But in the first case, you're saying, that i should store the customerId, not the URI. But what if the service is not exposing this internals in the response? Then, imo, the URI is the only availabe unique resource identifier. But even if there is such data, in order to rebuild the URI, I´ll need to know how to build, based on a uri template.
– ibexit
Nov 8 at 19:58
@ibexit there is a certain assumption in case 1 that team know some internals of other service (how to discover the service and call the API's) . As Order and Customer Service are being developed on some core principles which the entire organization will abide, which will help them to speed up the development. If you framework like Lagom and other microservice framework they do these service discovery and all out of the box. Also imo building services such that one dosen't know a thing about the other in the same org is not the good idea as that will have larger overheads
– techagrammer
Nov 13 at 7:39
Hey @techagrammer, happy to see you back here. Just to make it more specific. Let's say service A is CategoryService, B is BookService. We need to categorize boolks. One book to store in a category is looking like this:GET http://example.com/books/123456 { “title“: “lorem ipsum“ }. How you would store the reference to the book in the CategoryService?
– ibexit
Nov 13 at 7:48
@ibexit in this assuming category have list of books and book can be in multiple categories, also assuming category service is not a very very generic service like tag in which you can tag anything, when I add a book in a category I will call API "example.com/category/1/addBook" data is {"bookId":"book-1"}. Now when category service store this it will query the book service and fetch the book details using the BookService Interface in Category Service by calling a function getBook - (which might internally hit it via REST or use GRPC ) and save {bookId : book-1 , title : book-title}.
– techagrammer
Nov 13 at 9:20
Got your point. But have you seen, there is no bookId in the books response?
– ibexit
Nov 13 at 9:39
add a comment |
up vote
1
down vote
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
answered Nov 8 at 11:59
techagrammer
678414
thank you @techagrammer for your answer! CASE2 is pretty clear -I#m with you in this case. But in the first case, you're saying, that i should store the customerId, not the URI. But what if the service is not exposing this internals in the response? Then, imo, the URI is the only availabe unique resource identifier. But even if there is such data, in order to rebuild the URI, I´ll need to know how to build, based on a uri template.
– ibexit
Nov 8 at 19:58
@ibexit there is a certain assumption in case 1 that team know some internals of other service (how to discover the service and call the API's) . As Order and Customer Service are being developed on some core principles which the entire organization will abide, which will help them to speed up the development. If you framework like Lagom and other microservice framework they do these service discovery and all out of the box. Also imo building services such that one dosen't know a thing about the other in the same org is not the good idea as that will have larger overheads
– techagrammer
Nov 13 at 7:39
Hey @techagrammer, happy to see you back here. Just to make it more specific. Let's say service A is CategoryService, B is BookService. We need to categorize boolks. One book to store in a category is looking like this:GET http://example.com/books/123456 { “title“: “lorem ipsum“ }. How you would store the reference to the book in the CategoryService?
– ibexit
Nov 13 at 7:48
@ibexit in this assuming category have list of books and book can be in multiple categories, also assuming category service is not a very very generic service like tag in which you can tag anything, when I add a book in a category I will call API "example.com/category/1/addBook" data is {"bookId":"book-1"}. Now when category service store this it will query the book service and fetch the book details using the BookService Interface in Category Service by calling a function getBook - (which might internally hit it via REST or use GRPC ) and save {bookId : book-1 , title : book-title}.
– techagrammer
Nov 13 at 9:20
Got your point. But have you seen, there is no bookId in the books response?
– ibexit
Nov 13 at 9:39
add a comment |
up vote
1
down vote
up vote
1
down vote
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
answered Nov 8 at 11:59
techagrammer
678414
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
answered Nov 8 at 11:59
techagrammer
678414
answered Nov 8 at 11:59
techagrammer
678414
answered Nov 8 at 11:59
techagrammer
678414
answered Nov 8 at 11:59
techagrammer
678414
678414
thank you @techagrammer for your answer! CASE2 is pretty clear -I#m with you in this case. But in the first case, you're saying, that i should store the customerId, not the URI. But what if the service is not exposing this internals in the response? Then, imo, the URI is the only availabe unique resource identifier. But even if there is such data, in order to rebuild the URI, I´ll need to know how to build, based on a uri template.
– ibexit
Nov 8 at 19:58
@ibexit there is a certain assumption in case 1 that team know some internals of other service (how to discover the service and call the API's) . As Order and Customer Service are being developed on some core principles which the entire organization will abide, which will help them to speed up the development. If you framework like Lagom and other microservice framework they do these service discovery and all out of the box. Also imo building services such that one dosen't know a thing about the other in the same org is not the good idea as that will have larger overheads
– techagrammer
Nov 13 at 7:39
Hey @techagrammer, happy to see you back here. Just to make it more specific. Let's say service A is CategoryService, B is BookService. We need to categorize boolks. One book to store in a category is looking like this:GET http://example.com/books/123456 { “title“: “lorem ipsum“ }. How you would store the reference to the book in the CategoryService?
– ibexit
Nov 13 at 7:48
@ibexit in this assuming category have list of books and book can be in multiple categories, also assuming category service is not a very very generic service like tag in which you can tag anything, when I add a book in a category I will call API "example.com/category/1/addBook" data is {"bookId":"book-1"}. Now when category service store this it will query the book service and fetch the book details using the BookService Interface in Category Service by calling a function getBook - (which might internally hit it via REST or use GRPC ) and save {bookId : book-1 , title : book-title}.
– techagrammer
Nov 13 at 9:20
Got your point. But have you seen, there is no bookId in the books response?
– ibexit
Nov 13 at 9:39
add a comment |
thank you @techagrammer for your answer! CASE2 is pretty clear -I#m with you in this case. But in the first case, you're saying, that i should store the customerId, not the URI. But what if the service is not exposing this internals in the response? Then, imo, the URI is the only availabe unique resource identifier. But even if there is such data, in order to rebuild the URI, I´ll need to know how to build, based on a uri template.
– ibexit
Nov 8 at 19:58
@ibexit there is a certain assumption in case 1 that team know some internals of other service (how to discover the service and call the API's) . As Order and Customer Service are being developed on some core principles which the entire organization will abide, which will help them to speed up the development. If you framework like Lagom and other microservice framework they do these service discovery and all out of the box. Also imo building services such that one dosen't know a thing about the other in the same org is not the good idea as that will have larger overheads
– techagrammer
Nov 13 at 7:39
Hey @techagrammer, happy to see you back here. Just to make it more specific. Let's say service A is CategoryService, B is BookService. We need to categorize boolks. One book to store in a category is looking like this:GET http://example.com/books/123456 { “title“: “lorem ipsum“ }. How you would store the reference to the book in the CategoryService?
– ibexit
Nov 13 at 7:48
@ibexit in this assuming category have list of books and book can be in multiple categories, also assuming category service is not a very very generic service like tag in which you can tag anything, when I add a book in a category I will call API "example.com/category/1/addBook" data is {"bookId":"book-1"}. Now when category service store this it will query the book service and fetch the book details using the BookService Interface in Category Service by calling a function getBook - (which might internally hit it via REST or use GRPC ) and save {bookId : book-1 , title : book-title}.
– techagrammer
Nov 13 at 9:20
Got your point. But have you seen, there is no bookId in the books response?
– ibexit
Nov 13 at 9:39
thank you @techagrammer for your answer! CASE2 is pretty clear -I#m with you in this case. But in the first case, you're saying, that i should store the customerId, not the URI. But what if the service is not exposing this internals in the response? Then, imo, the URI is the only availabe unique resource identifier. But even if there is such data, in order to rebuild the URI, I´ll need to know how to build, based on a uri template.
– ibexit
Nov 8 at 19:58
thank you @techagrammer for your answer! CASE2 is pretty clear -I#m with you in this case. But in the first case, you're saying, that i should store the customerId, not the URI. But what if the service is not exposing this internals in the response? Then, imo, the URI is the only availabe unique resource identifier. But even if there is such data, in order to rebuild the URI, I´ll need to know how to build, based on a uri template.
– ibexit
Nov 8 at 19:58
@ibexit there is a certain assumption in case 1 that team know some internals of other service (how to discover the service and call the API's) . As Order and Customer Service are being developed on some core principles which the entire organization will abide, which will help them to speed up the development. If you framework like Lagom and other microservice framework they do these service discovery and all out of the box. Also imo building services such that one dosen't know a thing about the other in the same org is not the good idea as that will have larger overheads
– techagrammer
Nov 13 at 7:39
@ibexit there is a certain assumption in case 1 that team know some internals of other service (how to discover the service and call the API's) . As Order and Customer Service are being developed on some core principles which the entire organization will abide, which will help them to speed up the development. If you framework like Lagom and other microservice framework they do these service discovery and all out of the box. Also imo building services such that one dosen't know a thing about the other in the same org is not the good idea as that will have larger overheads
– techagrammer
Nov 13 at 7:39
Hey @techagrammer, happy to see you back here. Just to make it more specific. Let's say service A is CategoryService, B is BookService. We need to categorize boolks. One book to store in a category is looking like this:
GET http://example.com/books/123456 { “title“: “lorem ipsum“ } . How you would store the reference to the book in the CategoryService?– ibexit
Nov 13 at 7:48
Hey @techagrammer, happy to see you back here. Just to make it more specific. Let's say service A is CategoryService, B is BookService. We need to categorize boolks. One book to store in a category is looking like this:
GET http://example.com/books/123456 { “title“: “lorem ipsum“ } . How you would store the reference to the book in the CategoryService?– ibexit
Nov 13 at 7:48
@ibexit in this assuming category have list of books and book can be in multiple categories, also assuming category service is not a very very generic service like tag in which you can tag anything, when I add a book in a category I will call API "example.com/category/1/addBook" data is {"bookId":"book-1"}. Now when category service store this it will query the book service and fetch the book details using the BookService Interface in Category Service by calling a function getBook - (which might internally hit it via REST or use GRPC ) and save {bookId : book-1 , title : book-title}.
– techagrammer
Nov 13 at 9:20
@ibexit in this assuming category have list of books and book can be in multiple categories, also assuming category service is not a very very generic service like tag in which you can tag anything, when I add a book in a category I will call API "example.com/category/1/addBook" data is {"bookId":"book-1"}. Now when category service store this it will query the book service and fetch the book details using the BookService Interface in Category Service by calling a function getBook - (which might internally hit it via REST or use GRPC ) and save {bookId : book-1 , title : book-title}.
– techagrammer
Nov 13 at 9:20
Got your point. But have you seen, there is no bookId in the books response?
– ibexit
Nov 13 at 9:39
Got your point. But have you seen, there is no bookId in the books response?
– ibexit
Nov 13 at 9:39
add a comment |
up vote
0
down vote
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.
answered Nov 8 at 6:03
Anunay
904617
Thank you very mutch for your reply. I totally agree that a URL and response may change. I see the URI not (only) as a reference or way to get the entity, but manly as a Uniform Resource Idenifier. Of course, this URI don't have to be the URI of a particular service instance, but the URI based on a API gateway. If the URI changes for the very same entity, there should be permament redirects on the old URI. Now we'll be able to update the stored URI (if we want).The same applies for response changes - the old representation should be still there, available as a projection of the new format. ???
– ibexit
Nov 8 at 19:47
Its not just about them changing. URI are means to get data, and there could be other means as well. Rest endpoints just gives you an address to knock on and ask for data for given reference, tomorrow you may want to other means of these communication. IMO they should be separate. Also if you are in control of how changes should propagate in services you can take a call, but if you are not, I would rather not want to go through and update 100's of entries just because service Y or api gateway decided to rename the endpoints.final call is yours, if you think pros outweighs the cons, so be it.
– Anunay
Nov 9 at 5:24
add a comment |
up vote
0
down vote
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.
answered Nov 8 at 6:03
Anunay
904617
Thank you very mutch for your reply. I totally agree that a URL and response may change. I see the URI not (only) as a reference or way to get the entity, but manly as a Uniform Resource Idenifier. Of course, this URI don't have to be the URI of a particular service instance, but the URI based on a API gateway. If the URI changes for the very same entity, there should be permament redirects on the old URI. Now we'll be able to update the stored URI (if we want).The same applies for response changes - the old representation should be still there, available as a projection of the new format. ???
– ibexit
Nov 8 at 19:47
Its not just about them changing. URI are means to get data, and there could be other means as well. Rest endpoints just gives you an address to knock on and ask for data for given reference, tomorrow you may want to other means of these communication. IMO they should be separate. Also if you are in control of how changes should propagate in services you can take a call, but if you are not, I would rather not want to go through and update 100's of entries just because service Y or api gateway decided to rename the endpoints.final call is yours, if you think pros outweighs the cons, so be it.
– Anunay
Nov 9 at 5:24
add a comment |
up vote
0
down vote
up vote
0
down vote
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.
answered Nov 8 at 6:03
Anunay
904617
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.
answered Nov 8 at 6:03
Anunay
904617
answered Nov 8 at 6:03
Anunay
904617
answered Nov 8 at 6:03
Anunay
904617
answered Nov 8 at 6:03
Anunay
904617
904617
Thank you very mutch for your reply. I totally agree that a URL and response may change. I see the URI not (only) as a reference or way to get the entity, but manly as a Uniform Resource Idenifier. Of course, this URI don't have to be the URI of a particular service instance, but the URI based on a API gateway. If the URI changes for the very same entity, there should be permament redirects on the old URI. Now we'll be able to update the stored URI (if we want).The same applies for response changes - the old representation should be still there, available as a projection of the new format. ???
– ibexit
Nov 8 at 19:47
Its not just about them changing. URI are means to get data, and there could be other means as well. Rest endpoints just gives you an address to knock on and ask for data for given reference, tomorrow you may want to other means of these communication. IMO they should be separate. Also if you are in control of how changes should propagate in services you can take a call, but if you are not, I would rather not want to go through and update 100's of entries just because service Y or api gateway decided to rename the endpoints.final call is yours, if you think pros outweighs the cons, so be it.
– Anunay
Nov 9 at 5:24
add a comment |
Thank you very mutch for your reply. I totally agree that a URL and response may change. I see the URI not (only) as a reference or way to get the entity, but manly as a Uniform Resource Idenifier. Of course, this URI don't have to be the URI of a particular service instance, but the URI based on a API gateway. If the URI changes for the very same entity, there should be permament redirects on the old URI. Now we'll be able to update the stored URI (if we want).The same applies for response changes - the old representation should be still there, available as a projection of the new format. ???
– ibexit
Nov 8 at 19:47
Its not just about them changing. URI are means to get data, and there could be other means as well. Rest endpoints just gives you an address to knock on and ask for data for given reference, tomorrow you may want to other means of these communication. IMO they should be separate. Also if you are in control of how changes should propagate in services you can take a call, but if you are not, I would rather not want to go through and update 100's of entries just because service Y or api gateway decided to rename the endpoints.final call is yours, if you think pros outweighs the cons, so be it.
– Anunay
Nov 9 at 5:24
Thank you very mutch for your reply. I totally agree that a URL and response may change. I see the URI not (only) as a reference or way to get the entity, but manly as a Uniform Resource Idenifier. Of course, this URI don't have to be the URI of a particular service instance, but the URI based on a API gateway. If the URI changes for the very same entity, there should be permament redirects on the old URI. Now we'll be able to update the stored URI (if we want).The same applies for response changes - the old representation should be still there, available as a projection of the new format. ???
– ibexit
Nov 8 at 19:47
Thank you very mutch for your reply. I totally agree that a URL and response may change. I see the URI not (only) as a reference or way to get the entity, but manly as a Uniform Resource Idenifier. Of course, this URI don't have to be the URI of a particular service instance, but the URI based on a API gateway. If the URI changes for the very same entity, there should be permament redirects on the old URI. Now we'll be able to update the stored URI (if we want).The same applies for response changes - the old representation should be still there, available as a projection of the new format. ???
– ibexit
Nov 8 at 19:47
Its not just about them changing. URI are means to get data, and there could be other means as well. Rest endpoints just gives you an address to knock on and ask for data for given reference, tomorrow you may want to other means of these communication. IMO they should be separate. Also if you are in control of how changes should propagate in services you can take a call, but if you are not, I would rather not want to go through and update 100's of entries just because service Y or api gateway decided to rename the endpoints.final call is yours, if you think pros outweighs the cons, so be it.
– Anunay
Nov 9 at 5:24
Its not just about them changing. URI are means to get data, and there could be other means as well. Rest endpoints just gives you an address to knock on and ask for data for given reference, tomorrow you may want to other means of these communication. IMO they should be separate. Also if you are in control of how changes should propagate in services you can take a call, but if you are not, I would rather not want to go through and update 100's of entries just because service Y or api gateway decided to rename the endpoints.final call is yours, if you think pros outweighs the cons, so be it.
– Anunay
Nov 9 at 5:24
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53197563%2fmicroservices-rest-how-to-store-references-to-resources-in-other-service%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
