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

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

https://software.xsede.org/svn/sdi/activities/sdiact-214/trunk/Packages/XSEDE-IS-Web-API_DesignDocument-v0.3.pdf

https://software.xsede.org/svn/sdi/activities/sdiact-214/trunk/Packages/XSEDE-IS-Web-API_DesignDocument-v0.1.pdf

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