REVIEW-41: SDIACT-214 XSEDE-IS Warehouse Web API


General design and security risk review for the XSEDE Information Services Warehouse RESTful web API.

Review Summary

  • (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

Review Criteria

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:

  1. Is the proposed API design flexible enough to address evolving needs
  2. Is the proposed security and authentication sufficient
  3. Are there any design or security approaches that would enhance these APIs


Current Date: 2024-07-15
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 Created: 2017-02-22 1:34 pm
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
    VIEWED: 2019-10-03 14:58
  • Maytal Dahan
    VIEWED: 2020-11-05 15:35
  • 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

John-Paul Navarro
Eric Blau

Review Facilitator

Shava Smallen


Please post your comments using the "New topic" or "Post reply" buttons in the forum below.