You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SC generates Link header which contains up to 4 links: next, prev, first and last. These are used, instead of generating the links in SI, to page through the data.
The main benefit is making SI not dependent on the actual paging URL format of SC. The SI only needs to know how to initiate the search.
The actual goal is to be able to insert an intermediary between SI and SC. That intermediary could aggregate the results from multiple instances of SC without SI even knowing about its existence.
Page count
As part of the TF work of extending SC with the multi instance mode for audits we discovered that the page count is not possible to determine upfront by doing a simple calculation based on the assumed page size. Since we went from a simplified paging approach in contrast to keep the offsets per SC instance each page can return up to numberOfInstance * page_size worth of data. Audits cannot be assumed to be uniformly distributed. Based on that we figured having a page size visible at all time makes no sense. The ability to page through the data is more important than knowing how many pages there are.
Known endpoints
Previously ServiceInsight was using /endpoints which is essentially a mixture of multiple concerns. For example, the data structure returned there contains information like whether monitoring of the endpoint is on which is not relevant for SI. With the known endpoints API there are two distinct endpoints now. One for SI which contains only the SI relevant information and one for SP.
Info
Paging
SC generates
Link
header which contains up to 4 links: next, prev, first and last. These are used, instead of generating the links in SI, to page through the data.The main benefit is making SI not dependent on the actual paging URL format of SC. The SI only needs to know how to initiate the search.
The actual goal is to be able to insert an intermediary between SI and SC. That intermediary could aggregate the results from multiple instances of SC without SI even knowing about its existence.
Page count
As part of the TF work of extending SC with the multi instance mode for audits we discovered that the page count is not possible to determine upfront by doing a simple calculation based on the assumed page size. Since we went from a simplified paging approach in contrast to keep the offsets per SC instance each page can return up to
numberOfInstance * page_size
worth of data. Audits cannot be assumed to be uniformly distributed. Based on that we figured having a page size visible at all time makes no sense. The ability to page through the data is more important than knowing how many pages there are.Known endpoints
Previously ServiceInsight was using
/endpoints
which is essentially a mixture of multiple concerns. For example, the data structure returned there contains information like whether monitoring of the endpoint is on which is not relevant for SI. With the known endpoints API there are two distinct endpoints now. One for SI which contains only the SI relevant information and one for SP.Plan of attack
[ ] Supply instance ID for body fetchingNo longer required since SC will return the instance id in the provided body URLThe text was updated successfully, but these errors were encountered: