I’m hoping to get some feedback on a possible approach for representing API endpoint interactions by our customers.
One of our key product offerings to customers is access to our APIs and we’re trying to bring in our customer API interactions, including requests & responses, into a DV. This data would be fed in via a daily file that provides the previous day’s endpoint interactions from an in-house tracking solution.
I think we’d 2 hubs that would require some pre-staging work to get the BKs to the tracking data:
- Customer : BK = Company Number
- API : BK = Product Number
With a link for:
- Customer->API
I’m trying to figure out how to represent the data for the endpoint calls such as:
- endpoint name
- version
- Request DateTime
- Request JSON
- Response JSON
- Response Time
- Status Code
Would the right approach to treat each endpoint interaction as a record in a Customer->API link satellite? I could create an Endpoint Hub but our business doesn’t view the endpoints as standalone objects, they are parts of an API.
The business also wants to be able to report on the individual fields from the request & response JSON, would it make sense to create BV satellites with those fields or leave that to the process for populating the info marts?
Hi there Bwillms,
“they are parts of an API”
Are they parts of an API or part of the relationship between API and Customer? That will determine whether it’s best to put them in a link sat or in the hub sat.
“create BV satellites with those fields or leave that to the process for populating the info marts?”
You can do either, obviously we’re going to be biased here towards utilizing the DV benefits so remember that if these are things you’re interested in the bitemporal history of or any auditability concerns you’re likely to lose that if you just build it in the info-layer.
Sometimes skipping these steps can feel like a optimization but often the refactor time later is longer when some information passes through the vault and some is built into the info-layer. I find it easier to have the info-layer clean and simple just being an interface for the vault, since many analysts are more familiar with that structure.
All the best!
Frankie
Hi Frankie,
Thanks for the response, the part on BV makes sense.
On modelling the endpoint data:
Are they parts of an API or part of the relationship between API and Customer?
To me they could be both:
1 - The list of endpoints and their version history could be viewed similar to addresses and phone numbers, as the contact points for the API. So I could see this data as a Mulit-Active Satellite.
2 - The contact point our customer used for a specific interaction with our products.
Would there be an issue with having data in two satellites where the endpoint identifying fields would exist in both? Something like this with ENDPOINT_NAME & ENDPOINT_VERSION in both satellites (not representative of actual naming, structures or cardinalities):
1 Like
No issue with splitting your satellite by fields. I’d probably just stick with just the link sat but I don’t think any of your suggested approaches will bite you in the future so it’s dealers choice really 
Thanks for your input @Frankie, I appreciate it!
1 Like
