General design and security risk review for the XSEDE Information Services Warehouse RESTful web API.
- (Marlon) Figure 1 is confusing
- Added reference to Figure 1 in text and expanded on the description.
- (Marlon, Shava) What are router apps?
- Added more detailed description to explain role and scope.
- (Marlon) What is the difference in the data models/message formats exposed by the REST API and the pub/sub messaging system?
- (Marlon) E.2.3 states “The REST Service(s) availability target is 99.5. Information accessed thru the API needs to be accurate and up-to-date, so it needs to propagate from the source information system to the warehouse as quickly as possible. “ Explain what this means more concretely. What is the latency of information flow for various kinds of information in the system?
- Added an explanation of how many hours of downtime and added a table of latency to explain the different types of information and their frequency of updates,.
- (Marlon) How will you verify/monitor performance of the API?
- Responded in E.2.12 that Inca will be used to verify performance of each information type published in warehouse
- (Marlon) F.1.8 mentions data cross-referencing. Where is this described? What is the performance of queries?
- Added text to explain the performance should be efficient due to DB indexing.
- (Marlon) F2: what is the performance of a query on a JSON blob?
- Responded that they have not done a detailed analysis but so far has not been a limitation.
- (Marlon) The screen shot in G.2 isn’t very helpful.
- Added some sentences explaining the API documentation screenshot
- (Shava) Naming convention on APIs?
- Expanded text in F.1.9
Review Output Documents (Final)
Review Input Documents
This API provides an evolving set of interfaces to XSEDE-IS resource information. This review is not intended to establish whether the functional requirements of any specific client application are being met, but rather does the design seem flexible enough to evolve and address evolving needs.
Please focus on these questions:
- Is the proposed API design flexible enough to address evolving needs
- Is the proposed security and authentication sufficient
- Are there any design or security approaches that would enhance these APIs
ScheduleCurrent Date: 2019-01-18
Current Status: Closed (Design and Security Review)
|Target Date||Actual Date||Activity Milestone|
|2017-02-22||Review launch date|
|2017-03-10||Written feedback due (Reviewers)|
|2017-03-17||2017-04-21||Written response date (Review Material Developers)|
|2017-02-20||2017-04-21||Final approval due and completion date (Reviewers)|
Review Last Updated: 2017-04-21 3:26 pm
If you are a reviewer, please login to sign or withdraw from this review.
- Jim Basney
- Maytal Dahan
- David Hart
SIGNED: 2017-03-10 11:00
- Rob Light
SIGNED: 2017-03-10 10:22
- Lee Liming
- Marlon Pierce
SIGNED: 2017-03-06 11:53
- Amy Schuele
- Adam Slagell
Review Material Developers