RAPID: a knowledge-based assistant for designing web APIs

Abstract

With the rise in initiatives such as software ecosystems and Internet of Things (IoT), developing web Application Programming Interfaces (web APIs) has become an increasingly common practice. One main concern in developing web APIs is that they expose back-end systems and data toward clients. This exposure threatens critical non-functional requirements, such as the security of back-end systems, the performance of provided services, and the privacy of communications with clients. Although dealing with non-functional requirements during software design has been long studied, there is still no framework to specifically assist software developers in addressing these requirements in web APIs. In this paper, we introduce Rational API Designer (RAPID), an open-source assistant that advises on designing non-functional requirements in the architecture of web APIs. We have equipped RAPID with a broad range of expert knowledge about API design, systematically collected and extracted from the literature. The API design knowledge has been encoded as a set of 156 rules using the Non-Functional Requirements (NFR) multi-valued logic, a formal framework commonly used to describe non-functional and functional requirements of software systems. RAPID uses the encoded knowledge in a stepwise inference procedure to arrive from a given requirement, to a set of design alternatives to a final recommendation for a given API design specification. Seven well-experienced software engineers have blindly evaluated the accuracy of RAPID’s consultations over seven different cases of web API design and on providing design guidelines for thirty design questions. The results of the evaluation show that RAPID’s recommendations meet acceptable standards of the majority of the evaluators 73.3% of the time. Moreover, analysis of the evaluators’ comments suggests that more than one-third of the unacceptable ratings (33.8%) given to RAPID’s answers are due to valid but incomplete design guidelines. We thus expect that the accuracy of the consultations will increase as RAPID’s knowledge of API design is extended and refined.

This is a preview of subscription content, access via your institution.

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13
Fig. 14
Fig. 15
Fig. 16
Fig. 17
Fig. 18
Fig. 19
Fig. 20
Fig. 21
Fig. 22
Fig. 23
Fig. 24
Fig. 25
Fig. 26
Fig. 27

Notes

  1. 1.

    In the original NFR framework, XOR relationship between a set of variables is not explicitly defined. We define an XOR contribution of the form (Gi, Gj) \(\mathop{\longrightarrow}\limits^{\text{xor}}\) Gk between three variables of Gi, Gj, and Gk as following: Gk is satisficeable if one and only one of the two variables Gi and Gj is satisficed and the other variable is denied assuming that the interdependency itself is satisficed (i.e., the XOR contribution holds true). XOR contribution is an associative relation.

  2. 2.

    In Fig. 15, to simplify the implementation procedure, we have replaced the original “OR” relationship between design alternatives for “access authorization to API” to “XOR”.

  3. 3.

    In the pseudo code, there is a NFR-Evaluate(r) step. The details of this step are explained in Appendix 2.

  4. 4.

    https://github.com/m-h-s/RAPID.

  5. 5.

    “OR” rule types that have been altered to “XOR” in RAPID’s rule base are represented as “(x)or.”

References

  1. 1.

    Jansen S, Finkelstein A, Brinkkemper S (2009) A sense of community: a research agenda for software ecosystems. In: Proceedings of 31st international conference on software engineering-companion volume, pp 187–190. IEEE

  2. 2.

    Sadi MH, Yu E (2014) Analyzing the evolution of software development: From creative chaos to software ecosystems. In: 2014 IEEE eighth international conference on research challenges in information science (RCIS), pp 1–11. IEEE

  3. 3.

    Tan L, Wang N (2010) Future internet: the internet of things. In: 2010 3rd international conference on advanced computer theory and engineering (ICACTE), vol 5, pp V5–376. IEEE

  4. 4.

    Bosch J (2010) Architecture challenges for software ecosystems. In: Proceedings of the fourth European conference on software architecture: companion volume, pp 93–95. ACM

  5. 5.

    Weber RH (2010) Internet of things-new security and privacy challenges. Comput Law Secur Rev 26(1):23–30

    Article  Google Scholar 

  6. 6.

    Sicari S, Rizzardi A, Grieco LA, Coen-Porisini A (2015) Security, privacy, and trust in Internet of Things: the road ahead. Comput Netw 76:146–164

    Article  Google Scholar 

  7. 7.

    Myers BA, Stylos J (2016) Improving API usability. Commun ACM 59(6):62–69

    Article  Google Scholar 

  8. 8.

    Siriwardena P (2014) Advanced API security: securing APIs with OAuth 2.0, OpenID Connect, JWS, and JWE. Apress: Berkeley

  9. 9.

    De B (2017) API management: An architect’s guide to developing and managing APIs for your organization, 1st edn. Apress, Berkeley

    Google Scholar 

  10. 10.

    Vijayakumar T (2018) Practical API architecture and development with azure and AWS. Apress, Berkeley

    Google Scholar 

  11. 11.

    Akamai White Paper 1 (xxxx) Strategies for API protection. https://www.akamai.com/us/en/multimedia/documents/white-paper/akamai-strategies-for-api-security-white-aper.pdf?utm_source=twitter&utm_medium=social_organic&utm_campaign=api

  12. 12.

    Akamai White Paper 2 (xxxx) Solving API performance, reliability, and security challenges. https://www.akamai.com/uk/en/multimedia/documents/product-brief/akamai-solving-api-security-performance-for-enterprise-applications-focus-sheet.pdf

  13. 13.

    RFC 6749 (2012) The OAuth 2.0 authorization framework. https://tools.ietf.org/html/rfc6749

  14. 14.

    Sakimura N, Bradley J, Jones M, de Medeiros B, Mortimore C (2014) OpenID connect core 1.0 incorporating errata set 1. The OpenID Foundation, specification

  15. 15.

    Sakimura N, Bradley D, de Mederiso B, Jones M, Jay E (2012) OpenID connect standard 1.0-draft 09

  16. 16.

    Sun ST, Beznosov K (2012) The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems. In: Proceedings of the 2012 ACM conference on computer and communications security, pp 378–390. ACM

  17. 17.

    Li W, Mitchell CJ (2016) Analyzing the security of Google’s implementation of OpenID connect. In: International conference on detection of intrusions and malware, and vulnerability assessment. Springer, Cham, pp 357–376

  18. 18.

    Cataldo M, Herbsleb JD (2010) Architecting in software ecosystems: interface translucence as an enabler for scalable collaboration. In: Proceedings of the fourth European conference on software architecture: companion volume, pp 65–72. ACM

  19. 19.

    Stylos J, Myers B (2007) Mapping the space of API design decisions. In: IEEE symposium on visual languages and human-centric computing, 2007. VL/HCC 2007, pp 50–60. IEEE

  20. 20.

    Bloch J (2006) How to design a good API and why it matters. In: Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications, pp 506–507. ACM

  21. 21.

    Henning M (2009) API design matters. Commun ACM 52(5):46–56

    MathSciNet  Article  Google Scholar 

  22. 22.

    Richardson C (2015) Pattern: API gateway. Backend for front-end, pp 37–40. http://microservices.io/patterns/apigateway.html

  23. 23.

    Kitchenham B (2004) Procedures for performing systematic reviews. Keele UK Keele Univ 33(2004):1–26

    Google Scholar 

  24. 24.

    Dyba T, Kitchenham BA, Jorgensen M (2005) Evidence-based software engineering for practitioners. IEEE Softw 22(1):58–65

    Article  Google Scholar 

  25. 25.

    Wohlin C (2014) Guidelines for snowballing in systematic literature studies and a replication in software engineering. In: Proceedings of the 18th international conference on evaluation and assessment in software engineering, p 38. ACM

  26. 26.

    ISO/IEC TS 25011 (2017) Information technology-systems and software quality requirements and evaluation (SQuaRE)–service quality models. https://www.iso.org/obp/ui#iso:std:iso-iec:ts:25011:ed-1:v2:en

  27. 27.

    McLellan SG, Roesler AW, Tempest JT, Spinuzzi CI (1998) Building more usable APIs. IEEE Softw 15(3):78–86

    Article  Google Scholar 

  28. 28.

    Robillard MP (2009) What makes APIs hard to learn? Answers from developers. IEEE Softw 26(6):27–34

    Article  Google Scholar 

  29. 29.

    Robillard MP, Deline R (2011) A field study of API learning obstacles. Empir Softw Eng 16(6):703–732

    Article  Google Scholar 

  30. 30.

    Piccioni M, Furia CA, Meyer B (2013) An empirical study of API usability. In: 2013 ACM/IEEE international symposium on empirical software engineering and measurement, pp 5–14. IEEE

  31. 31.

    Gamma E, Helm R, Johnson R, Vlissides J (1993) Design patterns: abstraction and reuse of object-oriented design. In: European conference on object-oriented programming. Springer, Berlin, pp 406–431

  32. 32.

    Hogan A, Blomqvist E, Cochez M, d’Amato C, de Melo G, Gutierrez C, Navigli R (2020) Knowledge graphs. arXiv preprint arXiv:2003.02320

  33. 33.

    Chung L, Nixon BA, Yu E, Mylopoulos J (2000) Non-functional requirements in software engineering, vol 5. Springer

  34. 34.

    Susskind LE, McKearnen S, Thomas-Lamar J (1999) The consensus building handbook: a comprehensive guide to reaching agreement. Sage Publications, Oxford

    Google Scholar 

  35. 35.

    Jarke M, Loucopoulos P, Lyytinen K, Mylopoulos J, Robinson W (2011) The brave new world of design requirements. Inf Syst 36(7):992–1008

    Article  Google Scholar 

  36. 36.

    Sadi MH (2020) Assisting with API design through reusing design knowledge. Doctoral dissertation, University of Toronto, Canada

  37. 37.

    Thomas DR (2006) A general inductive approach for analyzing qualitative evaluation data. Am J Eval 27(2):237–246

    Article  Google Scholar 

  38. 38.

    Saldaña J (2009) The coding manual for qualitative researchers. Sage, Oxford

    Google Scholar 

  39. 39.

    Flick U (2009) An introduction to qualitative research. Sage Publications Limited, Oxford

    Google Scholar 

  40. 40.

    Gulwani S, Polozov O, Singh R (2017) Program synthesis. Found Trends Program Lang 4(1–2):1–119

    Google Scholar 

  41. 41.

    Alur R, Singh R, Fisman D, Solar-Lezama A (2018) Search-based program synthesis. Commun ACM 61(12):84–93

    Article  Google Scholar 

  42. 42.

    Robillard M, Walker R, Zimmermann T (2009) Recommendation systems for software engineering. IEEE Softw 27(4):80–86

    Article  Google Scholar 

  43. 43.

    Green C (1976) The design of the PSI program synthesis system. In: Proceedings of the 2nd international conference on Soft-ware engineering. IEEE Computer Society Press, pp 4–18

  44. 44.

    Rich C, Waters RC (1988) The Programmer’s apprentice: a research overview. Computer 21(11):10–25

    Article  Google Scholar 

  45. 45.

    Holmes R, Murphy GC (2005) Using structural context to recommend source code examples. In: Proceedings of the 27th international conference on Software engineering, pp 117–125

  46. 46.

    Holmes R, Walker RJ, Murphy GC (2005) Strathcona example recommendation tool. In: Proceedings of the 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering, pp 237–240

  47. 47.

    Mandelin D, Xu L, Bodík R, Kimelman D (2005) Jungloid mining: helping to navigate the API jungle. ACM Sigplan Notices 40(6):48–61

    Article  Google Scholar 

  48. 48.

    Thummalapenta S, Xie T (2007) Parseweb: a programmer assistant for reusing open source code on the web. In: Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering, pp 204–213

  49. 49.

    Zhong H, Xie T, Zhang L, Pei J, Mei H (2009) MAPO: mining and recommending API usage patterns. In: European conference on object-oriented programming. Springer, Berlin, pp 318–343

  50. 50.

    Hindle A, Barr ET, Su Z, Gabel M, Devanbu P (2012) On the naturalness of software. In: 2012 34th international conference on software engineering (ICSE), pp 837–847 IEEE

  51. 51.

    Raychev V, Vechev M, Yahav E (2014) Code completion with statistical language models. In: Proceedings of the 35th ACM SIGPLAN conference on programming language design and implementation, pp 419–428

  52. 52.

    Zhang H, Jain A, Khandelwal G, Kaushik C, Ge S, Hu W (2016) Bing developer assistant: improving developer productivity by recommending sample code. In: Proceedings of the 2016 24th ACM SIGSOFT international symposium on foun-dations of software engineering, pp 956–961

  53. 53.

    Wei Y, Chandrasekaran N, Gulwani S, Hamadi Y (2015) Building bing developer assistant. Technical Report. MSR-TR-2015-36, Microsoft Research

  54. 54.

    Shrobe H, Katz B, Davis R (2015) Towards a programmer’s apprentice (again). Center for Brains, Minds and Machines (CBMM)

  55. 55.

    Dean T, Chiang M, Gomez M, Gruver N, Hindy Y, Lam M, Wang L (2018) Amanuensis: the programmer’s apprentice. arXiv:1807.00082

  56. 56.

    Moritz D, Wang C, Nelson GL, Lin H, Smith AM, Howe B, Heer J (2019) Formalizing visualization design knowledge as constraints: actionable and extensible models in Draco. IEEE Trans Visual Comput Graphics 25(1):438–448

    Article  Google Scholar 

  57. 57.

    Green C, Luckham D, Balzer R, Cheatham T, Rich C (1986) Kestrel Institute: report on knowledge-based software assistant. In: Readings in artificial intelligence and software engineering. Morgan Kaufmann, pp 377–428

  58. 58.

    Boehm B, In H (1996) Identifying quality-requirement conflicts. IEEE Softw 13(2):25–35

    Article  Google Scholar 

  59. 59.

    Kruchten P (2010) Where did all this good architectural knowledge go?. In: European conference on software architecture. Springer, Berlin, pp 5–6

  60. 60.

    Kazman R, Klein M, Barbacci M, Longstaff T, Lipson H, Carriere J (1998) The architecture trade-off analysis method. In: Fourth IEEE international conference on engineering of complex computer systems, ICECCS’98. Proceedings, pp 68–78. IEEE

  61. 61.

    Tang A, Jin Y, Han J (2007) A rationale-based architecture model for design traceability and reasoning. J Syst Softw 80(6):918–934

    Article  Google Scholar 

  62. 62.

    Dürschmid T, Kang E, Garlan D (2019) Trade-off-oriented development: making quality attribute trade-offs first-class. In: 2019 IEEE/ACM 41st international conference on software engineering: new ideas and emerging results (ICSE-NIER), pp 109–112. IEEE

  63. 63.

    Sadi MH, Yu E (2017a) Modeling and analyzing openness trade-offs in software platforms: a goal-oriented approach. In: International working conference on requirements engineering: foundation for software quality. Springer, Cham, pp 33–49

  64. 64.

    Sadi MH, Yu E (2017b) Accommodating openness requirements in software platforms: a goal-oriented approach. In: International conference on advanced information systems engineering. Springer, Cham, pp 44–59

  65. 65.

    Jackson D (2012) Software abstractions: logic, language, and analysis. MIT press, New York

    Google Scholar 

  66. 66.

    Nguyen MC, Sebastiani R, Giorgini P, Mylopoulos J (2018) Multi-objective reasoning with constraint goal models requirements engineering. Requir Eng 23(2):189–225

    Article  Google Scholar 

Download references

Acknowledgement

The first author thanks Prof. Marsha Chechik and Prof. Steve Easterbrook at the University of Toronto for their supervision throughout the course of the research reported in this paper. She also thanks the architects and software engineers at Google and Autodesk, and the domain experts at the University of Toronto for evaluating the results of this research and providing invaluable feedback. For the sake of anonymity and conformance with research ethics, we only mention their first names: Andy, Clayton, Daniel, Nick, Patrick, Rami, Saeed, and Zia.

Author information

Affiliations

Authors

Corresponding author

Correspondence to Mahsa H. Sadi.

Additional information

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Appendices

Appendix 1: The API design knowledge graphs

The API non-functional requirements

figurea

The API design techniques

figureb
figurec

The trade-offs of the API design techniques

figured
figuree

Appendix 2: A brief overview of NFR multi-valued logic

Variables and connectives

In NFR, variables are of the form G1, G2, … Gn and are referred to as soft goals. The relationship between variables are of type implication. The implication relationships are either positive: Gi \(\mathop{\longrightarrow}\limits^{{{\text{Help}\left( + \right)}}}\) Gj, Gi \(\mathop{\longrightarrow}\limits^{{{\text{Some}}+}}\) Gj, Gi \(\mathop{\longrightarrow}\limits^{{{\text{Make}\left( + + \right)}}}\) Gj, or negative: Gi \(\mathop{\longrightarrow}\limits^{{{\text{Hurt}}\left( - \right)}}\) Gj, Gi \(\mathop{\longrightarrow}\limits^{{{\text{Some}}-}}\) Gj, Gi \(\mathop{\longrightarrow}\limits^{{{\text{Break}}\left( { - - } \right)}}\) Gj, or unknown: Gi \(\mathop{\longrightarrow}\limits^{{{\text{Unknwon}}\left( ? \right)}}\) Gj, or combinatorial \((G_{1} , \ldots , G_{m} )\mathop{\longrightarrow}\limits^{\text{and}}G_{n}\), \(\left( {G_{1} , \ldots ,G_{m} } \right)\mathop{\longrightarrow}\limits^{\text{or}}G_{n}\).

Evaluating variables

Value assignment

A soft goal Gi receives a satisfaction value which is in the range of {Denied, Weakly Denied (or partially Denied), Conflict, Undetermined, Weakly Satisfied (or Partially Satisficed), Satisficed}.

$${\text{Sat}}(G_{i} ) \in \left\{ {{\text{Den}},{\text{Pden}}, U,{\text{Conf}},{\text{PSat}},{\text{Sat}}} \right\}$$

The partial ordering between values is as follows:

$${\text{Den}} < {\text{PDen}} \le U \approx {\text{Conf}} \le {\text{Psat}} < {\text{Sat}}$$

We use : = to assign a satisfaction value to a soft goal (e.g., Gi = Den or Gi : = Sat). A soft goal receives a satisfaction value either as direct input or by propagation rules.

Value propagation rules

Once the satisfaction value of a soft goal Gi is determined, the satisfaction values of the existing statements of which Gi is a part can be checked using the propagation rules as described in the following.

$$\begin{aligned} & G_{i} \mathop{\longrightarrow}\limits^{{{\text{Help}}\left( + \right)}}G_{j} :\left\{ {\begin{array}{*{20}l} {G_{j} : = {\text{PSat}}} \hfill & {{\text{if}}\;G_{i} : = {\text{Sat}}\;{\text{or}}\;G_{i} : = {\text{PSat}}} \hfill \\ {G_{j} : = {\text{PDen}}} \hfill & {{\text{if}}\;G_{i} : = {\text{Den}}\;{\text{or}}\;G_{i} : = {\text{PDen}}} \hfill \\ {G_{j} : = G_{i} } \hfill & {{\text{if}}\;G_{i} : = {\text{Conf}}\;{\text{or}}\;G_{i} : = U} \hfill \\ \end{array} } \right\} \\ & G_{i} \mathop{\longrightarrow}\limits^{{{\text{Hurt}}\left( - \right)}}G_{j} :\left\{ {\begin{array}{*{20}l} {G_{j} : = {\text{PDen}}} \hfill & {{\text{if}}\;G_{i} : = {\text{Sat}}\;{\text{or}}\;G_{i} : = {\text{PSat}}} \hfill \\ {G_{j} : = {\text{PSat}}} \hfill & {{\text{if}}\;G_{i} : = {\text{Den}}\;{\text{or}}\;G_{i} : = {\text{PDen}}} \hfill \\ {G_{j} : = G_{i} } \hfill & {{\text{if}}\;G_{i} : = {\text{Conf}}\;{\text{or}}\;G_{i} : = U} \hfill \\ \end{array} } \right\} \\ & G_{i} \mathop{\longrightarrow}\limits^{{{\text{Make}}\left( { + + } \right)}}G_{j} :G_{j} : = G_{k} \\ & G_{i} \mathop{\longrightarrow}\limits^{{{\text{Break}}\left( { - - } \right)}}G_{j} :\left\{ {\begin{array}{*{20}l} {G_{j} : = {\text{PDen}}} \hfill & {{\text{if}}\;G_{i} : = {\text{Sat}}\;{\text{or}}\;G_{i} : = {\text{PSat}}} \hfill \\ {G_{j} : = {\text{PSat}}} \hfill & {{\text{if}}\;G_{i} : = {\text{Den}}\;{\text{or}}\;G_{i} : = {\text{PDen}}} \hfill \\ {G_{j} : = G_{i} } \hfill & {{\text{if}}\;G_{i} : = {\text{Conf}}\;{\text{or}}\;G_{i} : = U} \hfill \\ \end{array} } \right\} \\ & G_{i} \mathop{\longrightarrow}\limits^{{{\text{Some}}+}}G_{j} :\left\{ {\begin{array}{*{20}l} {G_{j} : = {\text{PSat}}} \hfill & {{\text{if}}\;G_{i} : = {\text{Sat}}\;{\text{or}}\;G_{i} : = {\text{PSat}}} \hfill \\ {G_{j} : = {\text{PDen}}} \hfill & {{\text{if}}\;G_{i} : = {\text{Den}}\;{\text{or}}\;G_{i} : = {\text{PDen}}} \hfill \\ {G_{j} : = G_{i} } \hfill & {{\text{if}}\;G_{i} : = {\text{Conf}}\;{\text{or}}\;G_{i} : = U} \hfill \\ \end{array} } \right\} \\ & G_{i} \mathop{\longrightarrow}\limits^{{{\text{Some}}-}}G_{j} :\left\{ {\begin{array}{*{20}l} {G_{j} : = {\text{PDen}}} \hfill & {{\text{if}}\;G_{i} : = {\text{Sat}}\;{\text{or}}\;G_{i} : = {\text{PSat}}} \hfill \\ {G_{j} : = {\text{PSat}}} \hfill & {{\text{if}}\;G_{i} : = {\text{Den}}\;{\text{or}}\;G_{i} : = {\text{PDen}}} \hfill \\ {G_{j} : = G_{i} } \hfill & {{\text{if}}\;G_{i} : = {\text{Conf}}\;{\text{or}}\;G_{i} : = U} \hfill \\ \end{array} } \right\} \\ & G_{i} \mathop{\longrightarrow}\limits^{{{\text{Unknown}}\left( ? \right)}}G_{j} :G_{j} : = U \\ & G_{i} \mathop{\longrightarrow}\limits^{{{\text{Equal}}\left( = \right)}}G_{j} :G_{j} : = G_{i} \\ & \left( {G_{i} ,G_{j} } \right)\mathop{\longrightarrow}\limits^{\text{and}}G_{k} :G_{k} : = \hbox{min} \left( {G_{i} ,G_{j} } \right) \\ & \left( {G_{i} ,G_{j} } \right)\mathop{\longrightarrow}\limits^{\text{or}}G_{k} :G_{k} : = \text{m} {\text{ax}}\left( {G_{i} ,G_{j} } \right) \\ & G_{i} \mathop{\longrightarrow}\limits^{*}G_{j} :G_{j} : = U\;{\text{if}}\;G_{i} : = U \\ & G_{i} \mathop{\longrightarrow}\limits^{{{\text{*}} }}G_{j} :\left\{ {\begin{array}{*{20}l} {G_{j} : = U} \hfill & {{\text{if}}\;G_{i} \mathop{\longrightarrow}\limits^{Unknown\left( ? \right)}G_{j} {\text{and}}\;G_{i} : = {\text{Conf}}} \hfill \\ { G_{j} : = {\text{Conf}}} \hfill & {{\text{else}}\;G_{i} : = {\text{Conf}}} \hfill \\ \end{array} } \right\} \\ \end{aligned}$$

Value resolution rules

After each step of value propagation, a soft goal Gi may receive several possibly conflicting or inconsistent values. To determine the final value of the soft goal Gi, a set of value resolution rules are used. Some value resolutions rules have only one possible outcome while other may have several outcomes. Those resolution rules with several outcomes require human decision to identify the final value. The value resolution rules are as followsFootnote 5:

$$\begin{aligned} & \frac{{G_{i} \mathop{\xrightarrow{{\text{Make}}\left( { + + } \right)}}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Make}}\left( { + + } \right)}}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Sat}}}}{{\frac{{G_{k} \text{ := }{\text{Sat}},\;G_{k} \text{ := }{\text{Sat}}}}{{G_{k} : = {\text{Sat}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Make}}\left( { + + } \right)}}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Break}}\left( { - - } \right)}}\limits{}G_{k} ,G_{i} \text{ := }{\text{Den}},G_{j} \text{ := }{\text{Sat}}}}{{\frac{{G_{k} \text{ := }{\text{Den}},\;G_{k} \text{ := }{\text{Den,}}}}{{G_{k} : = {\text{Den}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Break}}\left( { - - } \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Break}}\left( { - - } \right)}}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Sat}}}}{{\frac{{G_{k} \text{ := }{\text{Den}},\;G_{k} \text{ := }{\text{Den,}}}}{{G_{k} : = {\text{Den}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Break}}\left( { - - } \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Break}}\left( { - - } \right)}}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Sat}}}}{{\frac{{G_{k} \text{ := }{\text{Den}},\;G_{k} \text{ := }{\text{Den,}}}}{{G_{k} : = {\text{Den}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Make}}\left( { + + } \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Break}}\left( { - - } \right)}}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Sat}}}}{{\frac{{G_{k} \text{ := }{\text{Sat}},\;G_{k} \text{ := }{\text{Den}}}}{{G_{k} : = {\text{Conf}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Help}}\left( + \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Help}}\left( + \right)}}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Den}}}}{{\frac{{G_{k} \text{ := }{\text{PSat}},\;G_{k} \text{ := }{\text{PDen}}}}{{G_{k} : = {\text{Conf}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Some}}\left( + \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Some}}\left( + \right)}}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Den}}}}{{\frac{{G_{k} \text{ := }{\text{PSat}},\;G_{k} \text{ := }{\text{PDen}}}}{{G_{k} : = {\text{Conf}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Hurt}}\left( - \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Hurt}}\left( - \right)}}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Den}}}}{{\frac{{G_{k} \text{ := }{\text{PDen}},\;G_{k} \text{ := }{\text{PSat}}}}{{G_{k} : = {\text{Conf}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Some}}\left( - \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Some}} - }}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Den}}}}{{\frac{{G_{k} \text{ := }{\text{PDen}},\;G_{k} \text{ := }{\text{PSat}}}}{{G_{k} : = {\text{Conf}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Break}}\left( { - - } \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Break}}\left( { - - } \right)}}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Den}}}}{{\frac{{G_{k} \text{ := }{\text{Den}},\;G_{k} \text{ := }{\text{PSat}}}}{{{\text{Human}}\;{\text{decision}}\;{\text{required}} - G_{k} : = {\text{PDen}}\;{\text{or}}\;G_{k} : = {\text{Den}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Break}}\left( { - - } \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Make}}\left( { + + } \right)}}\limits{}G_{k} ,G_{i} \text{ := }{\text{Den}},G_{j} \text{ := }{\text{Sat}}}}{{\frac{{G_{k} \text{ := }{\text{PSat}},\;G_{k} \text{ := }{\text{Sat}}}}{{{\text{Human}}\;{\text{decision}}\;{\text{required}} - G_{k} : = {\text{PSat}}\;{\text{or}}\;G_{k} : = {\text{Sat}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Make}}\left( { + + } \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Some}} + }}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Sat}}}}{{\frac{{G_{k} \text{ := }{\text{Sat}},\;G_{k} \text{ := }{\text{PDen}}}}{{{\text{Human}}\;{\text{decision}}\;{\text{required}} - G_{k} : = {\text{Conf}}\;{\text{or}}\;G_{k} : = {\text{PSat}}\;{\text{or}}\;G_{k} : = {\text{Sat}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Make}}\left( { + + } \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Some}} - }}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Den}}}}{{\frac{{G_{k} \text{ := }{\text{Sat}},\;G_{k} \text{ := }{\text{PSat}}}}{{{\text{Human}}\;{\text{decision}}\;{\text{required}} - G_{k} : = {\text{PSat}}\;{\text{or}}\;G_{k} : = {\text{PSat}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Make}}\left( { + + } \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Some}} + }}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Den}}}}{{\frac{{G_{k} \text{ := }{\text{Sat}},\;G_{k} \text{ := }{\text{PSat}}}}{{{\text{Human}}\;{\text{decision}}\;{\text{required}} - G_{k} : = {\text{Conf}}\;{\text{or}}\;G_{k} : = {\text{PSat}}\;{\text{or}}\;G_{k} : = {\text{Sat}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Break}}\left( { - - } \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Some}} + }}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Sat}}}}{{\frac{{G_{k} \text{ := }{\text{Den}},\;G_{k} \text{ := }{\text{PSat}}}}{{{\text{Human}}\;{\text{decision}}\;{\text{required}} - G_{k} : = {\text{Conf}}\;{\text{or}}\;G_{k} : = {\text{PDen}}\;{\text{or}}\;G_{k} : = {\text{Den}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Break}}\left( { - - } \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Some}} + }}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Den}}}}{{\frac{{G_{k} \text{ := }{\text{Den}},\;G_{k} \text{ := }{\text{PDen}}}}{{{\text{Human}}\;{\text{decision}}\;{\text{required}} - G_{k} : = {\text{PDen}}\;{\text{or}}\;G_{k} : = {\text{Den}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Break}}\left( { - - } \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Some}} - }}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Den}}}}{{\frac{{G_{k} \text{ := }{\text{Den}},\;G_{k} \text{ := }{\text{PSat}}}}{{{\text{Human}}\;{\text{decision}}\;{\text{required}} - G_{k} : = {\text{Conf}}\;{\text{or}}\;G_{k} : = {\text{PDen}}\;{\text{or}}\;G_{k} : = {\text{Den}}}}}} \\ &\frac{{G_{i} \mathop{\xrightarrow{{\text{Help}}\left( + \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Help}}\left( + \right)}}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Sat}}}}{{\frac{{G_{k} \text{ := }{\text{PSat}},\;G_{k} \text{ := }{\text{PSat}}}}{{{\text{Human}}\;{\text{decision}}\;{\text{required}} - G_{k} : = {\text{PSat}}\;{\text{or}}\;G_{k} : = {\text{Sat}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Some}}\left( + \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Some}} + }}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Sat}}}}{{\frac{{G_{k} \text{ := }{\text{PSat}},\;G_{k} \text{ := }{\text{PSat}}}}{{{\text{Human}}\;{\text{decision}}\;{\text{required}} - G_{k} : = {\text{PSat}}\;{\text{or}}\;G_{k} : = {\text{Sat}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Hurt}}\left( - \right)}}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Hurt}}\left( - \right)}}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Sat}}}}{{\frac{{G_{k} \text{ := }{\text{PDen}},\;G_{k} \text{ := }{\text{PDen}}}}{{{\text{Human}}\;{\text{decision}}\;{\text{required}} - G_{k} : = {\text{PDen}}\;{\text{or}}\;G_{k} : = {\text{Den}}}}}} \\ & \frac{{G_{i} \mathop{\xrightarrow{{\text{Some}}- }}\limits{}G_{k} ,G_{j} \mathop{\xrightarrow{{\text{Some}} - }}\limits{}G_{k} ,G_{i} \text{ := }{\text{Sat}},G_{j} \text{ := }{\text{Sat}}}}{{\frac{{G_{k} \text{ := }{\text{PDen}},\;G_{k} \text{ := }{\text{PDen}}}}{{{\text{Human}}\;{\text{decision}}\;{\text{required}} - G_{k} : = {\text{PDen}}\;{\text{or}}\;G_{k} : = {\text{Den}}}}}} \\ \end{aligned}$$

Appendix 3: The list of rules available to RAPID

  1. 1.

    (Access Simplicity [API], Access Duration [API], Access Rate [API]) \(\mathop{\longrightarrow}\limits^{\text{and}}\) Accessibility [API]: NF-REF

  2. 2.

    (Compatibility with Minor Changes [API], Compatibility with Major Changes [API]) \(\mathop{\longrightarrow}\limits^{\text{and}}\) Evolvability [API]: NF-REF

  3. 3.

    (Understandability [API], Efficiency [API], Usage simplicity [API], Consistency [API]) \(\mathop{\longrightarrow}\limits^{\text{and}}\) Usability [API]: NF-REF

  4. 4.

    (Memorability [API]) \(\mathop{\longrightarrow}\limits^{\text{Help}}\) Usability [API]: NF-REF

  5. 5.

    (Response Time [API], Latency [API], Throughput [API], Availability [API]) \(\mathop{\longrightarrow}\limits^{\text{and}}\) Performance [API]: NF-REF

  6. 6.

    (Server-Side Extensibility [API], Client-Side Extensibility [API]) \(\mathop{\longrightarrow}\limits^{\text{and}}\) Extensibility [API]: NF-REF

  7. 7.

    (Flexibility in Message Format [API], Flexibility in Message Parameter [API], Flexibility in Communication Protocol [API]) \(\mathop{\longrightarrow}\limits^{\text{and}}\) Interoperability [API]: NF-REF

  8. 8.

    (Confidentiality [API], Privacy [API], Operational Security [API], Reliability [API]) \(\mathop{\longrightarrow}\limits^{\text{and}}\) Security [API]: NF-REF

  9. 9.

    (Message Confidentiality [API], Access Confidentiality [API]) \(\mathop{\longrightarrow}\limits^{\text{and}}\) Confidentiality [API]: NF-REF

  10. 10.

    (Robustness [API], Traceability [API]) \(\mathop{\longrightarrow}\limits^{\text{and}}\) Operational Security [API]: NF-REF

  11. 11.

    (Integrity [API]) \(\mathop{\longrightarrow}\limits^{\text{Help}}\) Reliability [API]: NF-REF

  12. 12.

    (Usability [API]) \(\mathop{\longrightarrow}\limits^{\text{and}}\) Adoptability [API]: NF-REF

  13. 13.

    (Interface Translation [ ]) \(\mathop{\longrightarrow}\limits^{\text{Help}}\) Compatibility with Minor Changes [API]: NF-OP

  14. 14.

    (Adapter [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Interface Translation [ ]: F-OP

  15. 15.

    (Supporting Multiple Versions of API at the Same Time [ ]) \(\mathop{\longrightarrow}\limits^{\text{Help}}\) Compatibility with Major Changes [API]: NF-OP

  16. 16.

    (Multiple Service Instances Handling Multiple API versions [ ], Single Service Instance Handling Multiple API versions [ ]) \(\mathop{\longrightarrow}\limits^{\text{xor}}\) Supporting Multiple Versions of API at the Same Time [ ]: F-OP

  17. 17.

    (Access Control [API]) \(\mathop{\longrightarrow}\limits^{\text{Help}}\) Access Confidentiality [API]: NF-OP

  18. 18.

    (Access Authorization [API], Key and Certificate Management [ ]) \(\mathop{\longrightarrow}\limits^{\text{and}}\) Access Control [API]: F-REF

  19. 19.

    (API-Key [ ], Username and Password [ ], Mutual Certificate-Based Authentication X.509 [ ], Open Authorization Version 2.0 [ ], OpenID Connect Version 1.0 [ ]) \(\mathop{\longrightarrow}\limits^{{\left( {\text{x}} \right){\text{or}}}}\) Access Authorization [API]: F-OP

  20. 20.

    (Securing Communication Channels [ ], Message Encryption [ ]) \(\mathop{\longrightarrow}\limits^{\text{or}}\) Message Confidentiality [API]: NF-OP

  21. 21.

    (End-User Notification and Approval upon API Access [ ], Data Masking [ ]) \(\mathop{\longrightarrow}\limits^{\text{or}}\) Privacy [API]: NF-OP

  22. 22.

    (Activity Logging [API], User Auditing [API]) \(\mathop{\longrightarrow}\limits^{\text{or}}\) Traceability [API]: NF-REF

  23. 23.

    (Failure Management [API], Threat Management [API]) \(\mathop{\longrightarrow}\limits^{\text{or}}\) Robustness [API]: NF-OP

  24. 24.

    (Failure Detection [API], Failure Prevention [API], Failure Recovery [API]) \(\mathop{\longrightarrow}\limits^{\text{or}}\) Failure Management [API]: F-REF

  25. 25.

    (Threat Detection [API], Threat Prevention [API]) \(\mathop{\longrightarrow}\limits^{\text{or}}\) Threat Management [API]: F-REF

  26. 26.

    (Circuit Breaker [ ], Response Time-Outs [ ]) \(\mathop{\longrightarrow}\limits^{{\left( {\text{x}} \right){\text{or}}}}\) Failure Detection [API]: F-OP

  27. 27.

    (Back-End Service Replication [ ], Congestion Control [API]) \(\mathop{\longrightarrow}\limits^{\text{or}}\) Failure Prevention [API]: F-REF

  28. 28.

    (Throttling [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Congestion Control [API]: F-REF

  29. 29.

    (Consumption Quota [ ], Concurrent Rate Limit [ ], Spike Arrest [ ]) \(\mathop{\longrightarrow}\limits^{{\left( {\text{x}} \right){\text{or}}}}\) Congestion Control [API]: F-OP

  30. 30.

    (Providing Fall Backs [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Failure Recovery [API]: F-REF

  31. 31.

    (Returning Empty Responses [ ], Returning Cached Responses [ ]) \(\mathop{\longrightarrow}\limits^{{\left( {\text{x}} \right){\text{or}}}}\) Providing Fall Backs [API]: F-OP

  32. 32.

    (Traffic Monitoring [API]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Threat Detection [API]: F-REF

  33. 33.

    (Detecting Unusual Request Loads [ ], Detecting Unusual Request Patterns [ ]) \(\mathop{\longrightarrow}\limits^{\text{or}}\) Traffic Monitoring [API]: F-REF

  34. 34.

    (Back-End Service Concurrency [ ] , Load Balancing and Distribution [ ]) \(\mathop{\longrightarrow}\limits^{\text{or}}\) Throughput [API]: NF-OP

  35. 35.

    (Round-Rubin Load Distribution [ ], Weighted Round-Rubin Load Distribution [ ], Least Connection Load Distribution [ ], Weighted Least Connection Load Distribution [ ], Random Load Distribution [ ]) \(\mathop{\longrightarrow}\limits^{\text{xor}}\) Load Balancing and Distribution [ ]: F-OP

  36. 36.

    (Caching [ ], Request Traffic Prioritization [ ]) \(\mathop{\longrightarrow}\limits^{\text{or}}\) Response Time [API ]: F-REF

  37. 37.

    (Caching Responses [API], Caching and Maintaining Connections to Back-End Services [API ] ) \(\mathop{\longrightarrow}\limits^{\text{or}}\) Caching [ ]: F-REF

  38. 38.

    (Caching Most Frequent Responses [ ], Caching Most Recent Responses [ ], Caching Most Probable Responses [ ]) \(\mathop{\longrightarrow}\limits^{{\left( {\text{x}} \right){\text{or}}}}\) Caching Responses [ ]: F-OP

  39. 39.

    (Connection Pooling [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Caching and Maintaining Connections to Back-End Services [API]: F-OP

  40. 40.

    (Back-End Service Replication [ ]) \(\mathop{\longrightarrow}\limits^{\text{Help}}\) Availability [API]: NF-OP

  41. 41.

    (API Gateway [ ], Service Registration [ ], Service Discovery [ ], Service Mapping and Composition [ ], Service Orchestration [ ]) \(\mathop{\longrightarrow}\limits^{\text{or}}\) Server-Side Extensibility [API]: NF-OP

  42. 42.

    (Central Gateway [ ], Multiple Gateways, Back-End for Front-End [ ]) \(\mathop{\longrightarrow}\limits^{\text{xor}}\) API Gateway [ ]: F-OP

  43. 43.

    (Self-Registration [ ], Third-Party Registration [ ]) \(\mathop{\longrightarrow}\limits^{\text{xor}}\) Service Registration [ ]: F-OP

  44. 44.

    (Server-Side Service Discovery [ ], Client-Side Service Discovery [ ]) \(\mathop{\longrightarrow}\limits^{\text{xor}}\) Service Discovery [ ]: F-OP

  45. 45.

    (Server-Side Service Mapping and Composition [ ], Server-Side Service Mapping and Composition [ ]) \(\mathop{\longrightarrow}\limits^{\text{xor}}\) Service Composition [ ]: F-OP

  46. 46.

    (Server-Side Service Two-Phase Transaction Management [ ], Client-Side Service Two-Phase Transaction Management [ ]) \(\mathop{\longrightarrow}\limits^{\text{xor}}\) Service Orchestration [ ]: F-OP

  47. 47.

    (Message Format Conversion [ ]) \(\mathop{\longrightarrow}\limits^{\text{Help}}\) Flexibility in message Format [API]: NF-OP

  48. 48.

    (JSON-XML Convertor [ ]) \(\mathop{\longrightarrow}\limits^{\text{Help}}\) Message Format Conversion [ ]: F-OP

  49. 49.

    (Interface Translation [ ]) \(\mathop{\longrightarrow}\limits^{\text{Help}}\) Flexibility in Message Parameters [API]: NF-OP

  50. 50.

    (Protocol Translation [ ]) \(\mathop{\longrightarrow}\limits^{\text{Help}}\) Flexibility in Communication Protocol [API]: NF-OP

  51. 51.

    (SOAP-REST Translation [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Protocol Translation [ ]: F-OP

  52. 52.

    (One-to-One Communication Style [API], One-to-Many Communication Style [API]) \(\mathop{\longrightarrow}\limits^{\text{or}}\) Communication Style [API]: F-REF

  53. 53.

    (Synchronous Communication [ ], Asynchronous Communication [ ], Synchronous to Asynchronous Communication [ ]) \(\mathop{\longrightarrow}\limits^{\text{xor}}\) One-to-One Communication Style [API]: F-OP

  54. 54.

    (Publish and Subscribe [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) One-to-Many Communication Style [API]

  55. 55.

    (API-Key [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Access Simplicity [API]: COR

  56. 56.

    (API-Key [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Usage Simplicity [API]: COR

  57. 57.

    (API-Key [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Latency [API]: COR

  58. 58.

    (API-Key [ ]) \(\mathop{\longrightarrow}\limits^{\text{Help}}\) Access Confidentiality [API]: COR

  59. 59.

    (API-Key [ ]) \(\mathop{\longrightarrow}\limits^{\text{Break}}\) Message Confidentiality [API]: COR

  60. 60.

    (API-Key [ ]) \(\mathop{\longrightarrow}\limits^{\text{Break}}\) Privacy [API]: COR

  61. 61.

    (Username and Password [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Access Simplicity [API]: COR

  62. 62.

    (Username and Password [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Usage Simplicity [API]: COR

  63. 63.

    (Username and Password [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Latency [API]: COR

  64. 64.

    (Username and Password [ ]) \(\mathop{\longrightarrow}\limits^{\text{Help}}\) Access Confidentiality [API]: COR

  65. 65.

    (Username and Password [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Message Confidentiality [API]: COR

  66. 66.

    (Username and Password [ ]) \(\mathop{\longrightarrow}\limits^{\text{Help}}\) Privacy [API]: COR

  67. 67.

    (Mutual Certificate-Based Authentication X.509 [ ]) \(\mathop{\longrightarrow}\limits^{\text{Break}}\) Access Simplicity [API]: COR

  68. 68.

    (Mutual Certificate-Based Authentication X.509 [ ]) \(\mathop{\longrightarrow}\limits^{\text{Break}}\) Usage Simplicity [API]: COR

  69. 69.

    (Mutual Certificate-Based Authentication X.509 [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Latency [API]: COR

  70. 70.

    (Mutual Certificate-Based Authentication X.509 [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Access Confidentiality [API]: COR

  71. 71.

    (Mutual Certificate-Based Authentication X.509 [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Message Confidentiality [API]: COR

  72. 72.

    (Mutual Certificate-Based Authentication X.509 [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Break}}^{ - - } }}\) Privacy [API]: COR

  73. 73.

    (Open Authorization Version 2.0 [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Access Simplicity [API]: COR

  74. 74.

    (Open Authorization Version 2.0 [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Usage Simplicity [API]: COR

  75. 75.

    (Open Authorization Version 2.0 [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Latency [API]: COR

  76. 76.

    (Open Authorization Version 2.0 [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Access Confidentiality [API]: COR

  77. 77.

    (Open Authorization Version 2.0 [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Message Confidentiality [API]: COR

  78. 78.

    (Open Authorization Version 2.0 [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Privacy [API]: COR

  79. 79.

    (OpenID Connect Version 1.0 [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Access Simplicity [API]: COR

  80. 80.

    (OpenID Connect Version 1.0 [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Usage Simplicity [API]: COR

  81. 81.

    (OpenID Connect Version 1.0 [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Break}} }}\) Latency [API]: COR

  82. 82.

    (OpenID Connect Version 1.0 [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Access Confidentiality [API]: COR

  83. 83.

    (OpenID Connect Version 1.0 [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Message Confidentiality [API]: COR

  84. 84.

    (OpenID Connect Version 1.0 [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Privacy [API]: COR

  85. 85.

    (Spike Arrest [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Availability [API]: COR

  86. 86.

    (Spike Arrest [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Latency [API]: COR

  87. 87.

    (Spike Arrest [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Robustness [API]: COR

  88. 88.

    (Spike Arrest [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Integrity [API]: COR

  89. 89.

    (Consumption Quota [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Availability [API]: COR

  90. 90.

    (Consumption Quota [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Robustness [API]: COR

  91. 91.

    (Consumption Quota [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Integrity [API]: COR

  92. 92.

    (Concurrent Rate Limit [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Availability [API]: COR

  93. 93.

    (Concurrent Rate Limit [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Latency [API]: COR

  94. 94.

    (Concurrent Rate Limit [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Robustness [API]: COR

  95. 95.

    (Concurrent Rate Limit [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Integrity [API]: COR

  96. 96.

    (Synchronous Communication [ ]) \(\mathop{\longrightarrow}\limits^{\text{Break}}\) Throughput [API]: COR

  97. 97.

    (Synchronous Communication [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Latency [API]: COR

  98. 98.

    (Synchronous Communication [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Robustness [API]: COR

  99. 99.

    (Synchronous Communication [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Integrity [API]: COR

  100. 100.

    (Asynchronous Communication [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Throughput [API]: COR

  101. 101.

    (Asynchronous Communication [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Latency [API]: COR

  102. 102.

    (Asynchronous Communication [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Robustness [API]: COR

  103. 103.

    (Asynchronous Communication [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Integrity [API]: COR

  104. 104.

    (Synchronous to Asynchronous Communication [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Throughput [API]: COR

  105. 105.

    (Synchronous to Asynchronous Communication [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Latency [API]: COR

  106. 106.

    (Synchronous to Asynchronous Communication [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Robustness [API]: COR

  107. 107.

    (Synchronous to Asynchronous Communication [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Integrity [API]: COR

  108. 108.

    (Synchronous to Asynchronous Communication [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Flexibility in Communication Protocol [API]: COR

  109. 109.

    (Publish and Subscribe [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Access Simplicity [API]: COR

  110. 110.

    (Publish and Subscribe [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Server-Side Extensibility [API]: COR

  111. 111.

    (Publish and Subscribe [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Client-Side Extensibility [API]: COR

  112. 112.

    (Publish and Subscribe [ ]) \(\mathop{\longrightarrow}\limits^{\text{Help}}\) Access Confidentiality [API]: COR

  113. 113.

    (Publish and Subscribe [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Response Time [API]: COR

  114. 114.

    (Central Gateway [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Server-Side Extensibility [API]: COR

  115. 115.

    (Central Gateway [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Throughput [API]: COR

  116. 116.

    (Central Gateway [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Response Time [API]: COR

  117. 117.

    (Central Gateway [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Access Confidentiality [API]: COR

  118. 118.

    (Multiple Gateway, Back-End for Front-End [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Server-Side Extensibility [API]: COR

  119. 119.

    (Multiple Gateway, Back-End for Front-End [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Throughput [API]: COR

  120. 120.

    (Multiple Gateway, Back-End for Front-End [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Response Time [API]: COR

  121. 121.

    (Multiple Gateway, Back-End for Front-End [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Access Confidentiality [API]: COR

  122. 122.

    (Third-Party Registration [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Usage Simplicity [API]: COR

  123. 123.

    (Third-Party Registration [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Server-Side Extensibility [API]: COR

  124. 124.

    (Third-Party Registration [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Access Confidentiality [API]: COR

  125. 125.

    (Third-Party Registration [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Usage Simplicity [API]: COR

  126. 126.

    (Third-Party Registration [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Server-Side Extensibility [API]: COR

  127. 127.

    (Third-Party Registration [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Access Confidentiality [API]: COR

  128. 128.

    (Server-Side Service Discovery [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Usage Simplicity [API]: COR

  129. 129.

    (Server-Side Service Discovery [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Server-Side Extensibility [API]: COR

  130. 130.

    (Server-Side Service Discovery [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Latency [API]: COR

  131. 131.

    (Server-Side Service Discovery [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Throughput [API]: COR

  132. 132.

    (Server-Side Service Discovery [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Access Confidentiality [API]: COR

  133. 133.

    (Server-Side Service Discovery [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Usage Simplicity [API]: COR

  134. 134.

    (Server-Side Service Discovery [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Server-Side Extensibility [API]: COR

  135. 135.

    (Server-Side Service Discovery [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Latency [API]: COR

  136. 136.

    (Server-Side Service Discovery [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Throughput [API]: COR

  137. 137.

    (Server-Side Service Discovery [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Access Confidentiality [API]: COR

  138. 138.

    (Server-Side API Mapping and Composition [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Usage Simplicity [API]: COR

  139. 139.

    (Server-Side API Mapping and Composition [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Server-Side Extensibility [API]: COR

  140. 140.

    (Server-Side API Mapping and Composition [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Latency [API]: COR

  141. 141.

    (Server-Side API Mapping and Composition [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Throughput [API]: COR

  142. 142.

    (Server-Side API Mapping and Composition [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Access Confidentiality [API]: COR

  143. 143.

    (Client-Side API Mapping and Composition [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Usage Simplicity [API]: COR

  144. 144.

    (Client-Side API Mapping and Composition [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Server-Side Extensibility [API]: COR

  145. 145.

    (Client-Side API Mapping and Composition [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Latency [API]: COR

  146. 146.

    (Client-Side API Mapping and Composition [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Throughput [API]: COR

  147. 147.

    (Client-Side API Mapping and Composition [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ - } }}\) Access Confidentiality [API]: COR

  148. 148.

    (Server-Side Two-Phase Transaction Management [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Usage Simplicity [API]: COR

  149. 149.

    (Server-Side Two-Phase Transaction Management [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Server-Side Extensibility [API]: COR

  150. 150.

    (Server-Side Two-Phase Transaction Management [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Latency [API]: COR

  151. 151.

    (Server-Side Two-Phase Transaction Management [ ]) \(\mathop{\longrightarrow}\limits^{\text{Make}}\) Throughput [API]: COR

  152. 152.

    (Server-Side Two-Phase Transaction Management [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Robustness [API]: COR

  153. 153.

    (Client-Side Two-Phase Transaction Management [ ]) \(\mathop{\longrightarrow}\limits^{\text{Break}}\) Usage Simplicity [API]: COR

  154. 154.

    (Client-Side Two-Phase Transaction Management [ ]) \(\mathop{\longrightarrow}\limits^{{{\text{Some}}^{ + } }}\) Server-Side Extensibility [API]: COR

  155. 155.

    (Client-Side Two-Phase Transaction Management [ ]) \(\mathop{\longrightarrow}\limits^{\text{Break}}\) Latency [API]: COR

  156. 156.

    (Client-Side Two-Phase Transaction Management [ ]) \(\mathop{\longrightarrow}\limits^{\text{Break}}\) Throughput [API]: COR

Appendix 4: The API design question bank

  Question topics Example design questions
1 - “API Evolvability”
- “Backward Compatibility with Minor Changes”
- “The API needs to be upgraded and newer versions of the API need to be released. The changes are minor and only apply to API some request and response parameters. How to handle compatibility with the current version of the API for the clients who are using the current version of the API.”
2 - “API Evolvability”
- “Backward Compatibility with Major Changes”
- “The API needs to be upgraded and newer versions of the API need to be released. The changes are major, and the API calls and the API address will also change. How to handle compatibility with the current version of the API.”
3 - “API Security”
- “Confidentiality”
- “Service Confidentiality”
- “Access Control”
- “Access Authorization”
- “How to secure access to the API?”
- “Design an access authorization mechanism for the API.”
- “Design an access control mechanism for the API.”
4 - “API Security”
- “Confidentiality”
- “Message Confidentiality”
- “How to protect and secure the API from eavesdropping (i.e., unauthorized listening to the API requests and responses.)”
- “Design a mechanism that protects the confidentiality of API interactions (requests and responses) with the clients.”
- “How to protect and security the API from man in the middle attack (i.e., changing the requests and responses that are communicated between the API and the clients.”
5 - “API Security”
- “Privacy”
- “Access Privacy”
- “How to protect the privacy of the end-user’s data upon access to the API.”
6 - “API Security”
- “Privacy”
- “Service Privacy”
- “How to protect the privacy of the data communicated with or stored by the API?”
7 - “API Security”
- “Operational Security”
- “Robustness”
- “Failure Prevention”
- “Congestion Control”
- “Throttling”
- “How to secure and protect the API from denial of service attacks (i.e., bombarding the back-end services with huge volumes of API calls so that other clients cannot access and use the API.”
- “How to protect the API from failure in the face of bursts in the traffic of API calls during peak times?”
- “Design a mechanism to help the API stay robust in the face of bursts in the traffic of API calls during peak times?”
- “How to protect the API from failure in providing service during peak times?”
- “Design a congestion control/throttling mechanism for the API.”
8 - “API Security”
- “Operational Security”
- “Robustness”
- “Failure Detection”
- “Back-end systems and service may become unavailable momentarily or permanently due to various reasons such as failure, upgrade, or disconnection from the network. Design a mechanism that helps the API to detect failure or unavailability of the back-end services.”
9 - “API Security”
- “Operational Security”
- “Robustness”
- “Failure Prevention”
- “Some Back-end systems and service may become unavailable momentarily or permanently due to various reasons such as failure, upgrade, or disconnection from the network. Design a mechanism that prevents the API from complete failure in responding to the clients’ requests.”
10 - “API Security”
- “Operational Security”
- “Robustness”
- “Failure Recovery”
- “Back-end systems and service may become unavailable momentarily or permanently due to various reasons such as failure, upgrade, or disconnection from the network. Design a mechanism that helps the API manage the situations when the back-end systems cannot respond to the clients.”
11 - “API Security”
- “Operational Security”
- “Robustness”
- “Threat Detection”
- “Malicious clients may attack the API and the back-end services and corrupt the healthy operation of the API. Design a mechanism that helps the API be robust against potential attacks or malicious usage.”
12 - “API Security”
- “Operational Security”
- “Traceability”
- “Malicious clients may steal the identity of the original clients and find access to the API. Design a mechanism that allows the API to trace identify theft attacks, and to trace the interactions with malicious clients.”
13 - “API Performance”
- “Throughput”
- “Load balancing”
- “Load distribution”
- “Design a mechanism that allows the API to gracefully manage and handle high volumes/load of API calls per second.”
- “How to handle high loads of API calls per second?”
- “Design a load balancing (or load distribution) mechanism for the API?”
14 - “API Performance”
- “Response Time”
- “Caching”
- “The API should respond to (numerous) clients in real-time (or timely manner). Design a mechanism that helps minimize the response of the API?”
- “Design a caching mechanism for the API.”
15 - “API Performance”
- “Response Time”
- “Traffic Prioritization”
- “The API should respond to the clients in real-time. Design a mechanism that allows the API to control its response time.”
16 - “API Performance”
- “Availability”
- “The API should be highly available. Design a mechanism that allows the API to be available even in the presence of failure in the back-end servers (services).”
17 - “API Extensibility”
- “Server-Side Extensibility”
- “Clients may request to upgrade or downgrade the provided service. Design a mechanism that allows easily to scale up or scale down the service of the API; i.e., to add or remove back-end services easily.
18 - “API Extensibility”
- “Server-Side Extensibility”
- “Clients may request to upgrade or downgrade the provided service. Design a mechanism that allows to easily scale up or scale down the service of the API; i.e., to add or remove back-end services easily.
19 - “API Extensibility”
- “Server-Side Extensibility”
- “Service Registry”
- “New service providers (or servers, data providers, or data sources) can register themselves as a back-end service for the API. Design a service registry mechanism for the API.
- “Design a mechanism that allows to dynamically add back-end services or servers to the API over time.
20 - “API Extensibility”
- “Server-Side Extensibility”
- “Service Discovery”
- “The back-end service providers (data sources) (or their location) change over time. Moreover, some back-end services may be unavailable in a specific time or be disconnected from the network. Design a mechanism that allows the API provider to find related back-end services.”
- “How to handle dynamic addition and removal of the back-end services.”
21 - “API Extensibility”
- “Server-Side Extensibility”
- “Service Composition”
- “The API uses a combination of other APIs to respond to the clients’ requests. How should the API be designed?”
22 - “API Extensibility”
- “Server-Side Extensibility”
- “Service Orchestration”
- “The API cooperates with other APIs to respond to the clients’ requests. How the API should be designed?”
23 - “API Communication Style”
- “Interaction Mechanism”
- “Design a communication style between the API and its clients.”
- “How should the API notify the clients of the updates?”
24 - “API Interoperability”
- “Flexibility in data format”
- “The API should be able to work with different types of clients and with varying data formats (e.g., (JSON, XML, or HTML)). How to handle flexibility in data format?”
25 - “API Interoperability”
- “Flexibility in communication protocol”
- “The API should work with different types of clients with various communication protocols (e.g., RESP, or SOAP). How to handle flexibility in communication protocol?”
26 - “API Interoperability”
- “Flexibility in
message parameters”
- “The API should work with clients having varying message formats (i.e., message header and query parameters). How to handle flexibility in message parameters?”

Appendix 5: The web API design exam and the answers provided by RAPID

A banking platform-the payment API

API specification

The Payment API enables online payment and allows to transfer fund from a given customer’s account to a destination account. The transfer is initiated by a client application or service. Access to the destination account is provided by a third-party account API provider.

The Payment API will be used in different scenarios such as online purchases (e.g., a merchant site that integrates secure bank payment).

Functional requirements

  • The client provides source account, destination account number, and the transfer amount. The API performs transfer an amount of fund from the source account to the destination account.

Non-functional requirements

  • Confidentiality and Privacy are Very Critical: Since the Payment API performs critical transactions on customers’ accounts, confidentiality and privacy are very critical requirements to the Payment API. The API should be immune against unauthorized access, and security attacks, such as (identity theft, man in the middle attack, and eavesdropping attacks).

  • Operational Security and Robustness are Very Critical: Correct and successful operation of the Payment API is very critical. The payment API should work correctly even in the case of failure of back-end services (for example, the third-party account provider API (the destination account provider) may be unavailable for some time, but the payment transaction should work correctly.

  • Availability is Very Critical: Since the online payment service is used in daily purchases and payment scenarios, it should be highly available (It should provide service 24 * 7 and have 99.95% uptime).

  • Interoperability is Critical: The payment API should be API to work with various clients having different communication protocols (such as SOAP or REST).

System/Platform Banking Platform
Name Payment API
Type of API Public (Open) Web API
Functionality/Data Provided by the API Performing online fund transfer between two accounts.
Important Requirements and Priority (1) Confidentiality of the API is very critical.
(2) Privacy of the API is very critical.
(3) Robustness of the API is very critical.
(4) Availability of the API is critical.
(5) Interoperability of the API is critical.
1 Question. Design an access authorization mechanism for the Payment API.
Question Topic. Access Authorization [API]
RAPID’s Answer. Either (a) Username and Password, or (b) Open Authorization Version 2.0, or (c) OpenID Connect Version 1.0.
Rating: Acceptable Identical: 2, Acceptable Alternative: 1, Partly Unacceptable:3, Don’t Know: 1
Status: Unacceptable *
2 Question. Design a mechanism that protects the confidentiality of the Payment API interactions (requests and responses) with the clients (the mechanism should protect the Payment API from eavesdropping and unauthorized listening to the API interactions with the clients.)
Question Topic. Message Confidentiality [API]
RAPID’s Answer. (a) Secure communication channels or (b) Message Encryption.
Rating: Acceptable Identical: 3, Acceptable Alternative: 1, Partly Unacceptable: 3
Status: Acceptable
3 Question. “Design a communication style between the Payment API and its clients.”
Question Topic. Communication Style [API]
RAPID’s Answer. Synchronous to Asynchronous Communication Style
Rating: Acceptable Identical: 2, Acceptable Alternative: 1, Partly Unacceptable: 2, Unacceptable: 1, Insufficient information: 2
Status: Unacceptable *
4 Question. “Malicious clients may steal the identity of the original clients and find access to the Payment API. Design a mechanism that allows the payment API to trace identify theft attacks.”
Question Topic. Traceability [API]
RAPID’s Answer. (a) Activity Logging or (b) User Auditing.
Rating: Acceptable Identical: 1, Acceptable Alternative: 2, Partly Unacceptable: 2, Unacceptable: 1, Insufficient information: 1
Status: Unacceptable *
5 Question. The Payment API should be able to work with different types of clients and with varying data formats (e.g., (JSON, XML)). How to handle flexibility in message format?
Question Topic. Flexibility in Message Format [API]
RAPID’s Answer. Message format conversion, JSON-XML Convertor
Rating: Acceptable Identical: 2, Acceptable Alternative: 2, Partly Unacceptable: 1, Unacceptable: 2
Status: Acceptable
6 Question. The Payment API cooperates with a third-party account API to transfer money to the destination account. How to design the cooperation between the Payment API and the third-party account API to perform a transfer transaction?
Question Topic. Service Orchestration [ ]
RAPID’s Answer. Server-Side Two-Phase Transaction Management.
Rating: Acceptable Identical: 3, Acceptable Alternative: 1, Partly Unacceptable: 1, Don’t Know: 2
Status: Acceptable
7 Question. The third-party account API (i.e., the destination account provider) may become unavailable momentarily due to various reasons such as failure or disconnection from the web. Design a mechanism that helps the payment API to detect failure or unavailability of the destination account provider.
Question Topic. Failure Detection [API]
RAPID’s Answer. Either (a) Circuit Breaker (Pattern) or (b) Response Time-Outs.
Rating: Acceptable Identical: 3, Acceptable Alternative: 3, Partly Unacceptable: 1
Status: Acceptable

A weather map platform-the current weather API

API specification

The Current Weather API provides data about the current weather of more than 200,000 cities around the world. Weather data of the cities are frequently updated based on global models and data coming from more than 40,000 weather stations which are dispersed geographically. Weather stations and data sources providers can openly register themselves as a weather data provider and they can be added or removed dynamically over time.

The Weather API has different kinds of clients, including unknown applications and services which can access the API for free as well as customers and partner applications who pay for the use of API. Different clients have different limits for calling the API per day.

Functional requirements

  • Given the city name or the geographical coordinates of the city or the zip code of the city, the API provides data about the current weather of a given city.

Non-functional requirements

  • Fast Response Time and Low Latency are Very Critical: The Current Weather API should respond to the clients’ requests fast and immediately in the order of milliseconds).

  • Extensibility of the Back-End Data Sources is Critical: The back-end data sources (weather data providers) can be added and removed dynamically over time. New weather data providers can register themselves over time and provide weather measurement data. The weather data about a given city can be provided by several weather stations.

  • High Throughput is Critical: The Current Weather API should be able to manage and responds to high volumes of the API calls per second. (Assume that the Weather API should handle more than 30,000 API calls per second.)

  • Usage Simplicity is Important: The API should be simple and utterly convenient to use.

  • Flexibility in Message Parameters is Important: The current weather API should be flexible toward the message and data formats of different clients as well as their request parameters. For example, the clients may ask for the current weather of a city by providing the city name as the request parameter, or ask the weather by proving its longitude and latitude, or by zip code.

System/Platform Weather Map Platform
API Name The Current Weather API
Type of API Public (Open) Web API
Functionality/Data Provided by the API Providing Weather Data of a given city
Important Requirements (1) Response Time of the API is very critical.
(2) Latency of the API is very critical.
(3) Throughput of the API is critical.
(4) Server-Side Extensibility of the API is critical.
(5) Usage Simplicity of the API is important.
(6) Flexibility in message parameters of the API is important.
1 Question. Design an access control mechanism for the Current Weather API. Consider that the Current Weather API has different types of clients with different limits for API calls per day.
Question Topic. Access Control [API]
RAPID’s Answer. API-Key
Rating: Acceptable Identical: 4, Acceptable Alternative: 1, Partly Unacceptable: 2
Status: Acceptable
2 Question. Design a mechanism that allows the Current Weather API to gracefully handle 30,000 API calls per second.
Question Topic. Throughput [API]
RAPID’s Answer. (a) Back-end service concurrency and (b) Load distribution and balancing.
For load distribution: Either (a) Round-Rubin Distribution, or (b) Weighted Round Rubin Distribution, or (c) Least Connection Distribution, or (d) Weighted Least Connection Distribution, or (e) Random Load Distribution.
Rating: Acceptable Identical: 2, Acceptable Alternative: 2, Partly Unacceptable: 3
Status: Acceptable
3 Question. How to protect the Current Weather API from denial of service failures that might occur due to congestion in the traffic of clients’ requests?
Question Topic. Congestion Control [API]
RAPID’s Answer. Consumption Quota or Rate Limit.
Rating: Acceptable Identical: 4, Acceptable Alternative: 1, Partly Unacceptable:1, Unacceptable:1
Status: Acceptable
4 Question. The Current Weather API should respond to numerous clients in real-time. How to minimize the response time of the API?
Question Topic. Response Time [API]
RAPID’s Answer. (a) Caching responses of API or (b) Caching and Maintaining Connections to Back-end services.
For caching responses: Either (a) Caching most frequent responses, or (b) Caching most recent responses, or (c) Caching most Probable Reponses.
For caching and maintaining connections to the back-end services: Connection Pooling.
Rating: Acceptable Identical: 4, Acceptable Alternative: 2, Partly Unacceptable:1
Status: Acceptable
5 Question. Design a mechanism that allows to easily add or remove back-end weather data providers (weather stations) for the Weather API over time.
Question Topic. Server-Side Extensibility [API]
RAPID’s Answer. Third-party Service Registration.
Rating: Acceptable Identical: 5, Acceptable Alternative: 1, Partly Unacceptable:1
Status: Acceptable
6 Question. The network location (IP address) of weather data providers changes over time. Moreover, there may be several weather data providers that can provide the data about the weather of a given city. How to find related back-end weather data providers?
Question Topic. Service Discovery and Routing [ ]
RAPID’s Answer. Server-side service discovery and routing.
Rating: Acceptable Identical: 3, Acceptable Alternative: 1, Partly Unacceptable: 3
Status: Acceptable
7 Question. The Current Weather API should be able to work with different types of clients and with various message parameters (i.e., varying query parameters (such as city name, zip code, or geographical coordinates). How to handle flexibility in message parameters?
Question Topic. Flexibility in message parameters [API]
RAPID’s Answer. Adapter.
Rating: Acceptable Identical: 4, Acceptable Alternative: 3
Status: Acceptable

A cloud storage platform—the write bucket/object API

API specification

The Write Bucket/Object API allows to write a bucket or an object on a cloud storage service.

Functional requirements

  • Given the ID of a bucket or an object and its content, the API writes or updates the bucket or object on the storage system.

Non-functional requirements

  • High Throughput is Very Critical: The Write API should be able to handle high loads of API calls (Assume that the storage service should be able to handle 100 clients simultaneously, each of which can make 1000 API per second. Hence, the API should be able to handle 100*1000= 100,000 requests per second).

  • Privacy of Clients’ Data is Very Critical: Since the stored data belong to the clients, the privacy of the stored objects should be protected on the back-end data storage servers. The clients’ data should not be visible to unintended and unauthorized audience.

  • High Availability is Very Critical: The Write API should meet 99.5% uptime.

  • Operational Security and Robustness is Very Critical: The write and update operation should work correctly even in the face of failure of the back-end systems (e.g., data storage servers may fail during a write request). The write API should also be immune against corruption in the back-end data storage systems (the storage system may fail permanently). The written objects and buckets should not be corrupted or missed over time.

  • Server-Side Extensibility is Very Critical: The clients may need to scale up or down (i.e., upgrade, or downgrade) their space for writing and storing objects. The API should allow the client to seamlessly scale up or down the required storage service.

  • Access Confidentiality is Critical: The Write API should only be accessed by the client whose files and content are stored on the storage system.

System/Platform A Cloud Storage Platform
API Name The Write Bucket/Object API
Type of API Protected (Partner to Partner) Cloud API
Functionality/Data Provided by the API Returning back a bucket of stored objects
Important Requirements (1) Throughput of the API is Very Critical.
(2) Privacy of the API is Very Critical.
(3) Availability of the API is Very Critical.
(4) Robustness of the API is Very Critical.
(5) Server-Side Extensibility of the API is Very Critical.
(6) Access Confidentiality of the API is Critical.
1 Question: How to protect the privacy of the clients’ data that are received and stored by the Write API? The stored data on the cloud storage belongs to the clients. The storages servers should preserve the privacy of the users’ data.
Question Topic: Privacy [API]
RAPID’s Answer: (a) End-User Notification and Approval or (b) Data Masking.
Rating: Acceptable Alternative: 2, Partly Unacceptable: 2, Unacceptable: 2, Insufficient Information: 1
Status: Unacceptable *
2 Question: Design a mechanism that allows the Write API to gracefully manage and handle 100,000API calls per second.
Question Topic: Throughput [API]
RAPID’s Answer: (a) Back-end service concurrency, and (b) Load distribution and balancing.
For load distribution use: Either (a) Round-Rubin Distribution, or (b) Weighted Round Rubin Distribution, or (c) Least Connection Distribution, or (d) Weighted Least Connection Distribution, or (e) Random Load Distribution.
Rating: Acceptable Identical: 3, Acceptable Alternative: 1, Partly Unacceptable: 2, Don’t Know: 1
Status: Acceptable
3 Question: The Write API should be highly available. Design a mechanism that allows the API to be available even in the presence of failure in the back-end data storage servers.
Question Topic: Availability [API]
RAPID’s Answer: Back-End Service Replication.
Rating: Acceptable Identical: 4, Partly Unacceptable: 1, Insufficient Information: 1, Don’t Know: 1
Status: Acceptable
4 Question: Clients may request to upgrade or downgrade the storage service according to their storage needs. Design some mechanism that allows easily to scale up or scale down the service of the API; i.e., to add or remove back-end services easily.
Question Topic: Server-Side Extensibility [API]
RAPID’s Answer: (a) API Gateway or (b) Service Registration or (c) Service Discovery or (d) Service Mapping and Composition, or (e) Service Orchestration.
Rating: Acceptable Identical: 2, Acceptable Alternative: 1, Partly Unacceptable: 2, Unacceptable: 2
Status: Unacceptable*
5 Question: Back-end data sources may become unavailable momentarily or permanently due to various reasons such as failure. Design a mechanism that helps the Write API to proactively detect failure or unavailability of the back-end systems before complete failure.
Question Topic: Failure Detection [API]
RAPID’s Answer: Either (a) Circuit Breaker (Pattern) or (b) Response Time-Outs.
Rating: Acceptable Identical: 3, Acceptable Alternative: 1, Partly Unacceptable: 2, Unacceptable: 1
Status: Acceptable
6 Question: Malicious clients may attack the write API and the back-end services and corrupt the healthy operation of the API. Design a mechanism that helps the write API be robust against potential attacks or malicious usage.
Question Topic: Robustness [API]
RAPID’s Answer: Traffic Monitoring. In Traffic monitoring (a) detect unusual request loads, or (b) detect unusual request patterns.
Rating: Acceptable Identical: 2, Acceptable Alternative: 2, Partly Unacceptable: 1, Unacceptable: 1, Don’t Know: 1
Status: Acceptable

A vehicle control platform-the lock status API

API specification

The Lock Status API provides data about the lock status of a vehicle; i.e., It informs the clients whether the vehicle doors are locked or not. Remote client applications can connect to the Lock API via the vehicle WiFi and WLAN to check the lock status.

Functional requirements

  • Given the Vehicle ID, the API returns the lock status of the related vehicle.

Non-functional requirements

  • Access and Message Confidentiality is Very Critical: The Lock Status API should only be accessed by the clients who are authorized by the driver or owner of the vehicle. Moreover, the requests and responses of the lock status API should be immune against eavesdropping (i.e., unauthorized listening to the API interactions).

  • Low Latency is Critical: The Lock Status API should respond to the clients in real-time and in a timely manner.

  • Flexibility in Message and Data format is Important: The Lock Status API should be able to provide lock status data in different formats, such as JSON, XML, HTML and should be able to work with client applications having various message formats.

  • Evolvability is Important: The Lock Status API may evolve over time and newer versions of the API with different message (request and response) parameters will be available over time.

System/Platform A Vehicle Control Platform
API Name The Lock Status API
Type of API Open Web API
Functionality/Data Provided by the API Informing the clients of the lock status of a vehicle.
Important Requirements (1) Access Confidentiality of the API is Very Critical.
(2) Message Confidentiality of the API is Very Critical.
(3) Latency of the API is Critical.
(4) Flexibility in message and data format of the API is important.
(5) Evolvability of the API is important.
1 Question: Design an access authorization mechanism for the Lock Status API.
Question Topic: Access Authorization [API]
RAPID’s Answer: Mutual Certificate-Based Authentication X .509.
Rating: Acceptable Identical: 5, Partly Unacceptable: 2
Status: Acceptable
2 Question. Design a mechanism that protects the confidentiality of Lock Status API interactions (requests and responses) with the clients.
Question Topic: Message Confidentiality [API]
RAPID’s Answer: (a) Secure communication channels or (b) Message Encryption (request and response encryption).
Rating: Acceptable Identical: 5, Acceptable Alternative: 2
Status: Acceptable
3 Question. Newer versions of the Lock Status API will be released over time that might differ in the message parameters. How to handle compatibility with the current version of the API.
Question Topic: Compatibility with Minor Changes [API]
RAPID’s Answer. Adapter.
Rating: Acceptable Identical: 1, Acceptable Alternative: 5, Partly Unacceptable: 1
Status: Acceptable

A flight data platform-the flight time table API

API specification

The Flight Time Table API provides data about the status and schedule of any flight around the world. The flight information includes take-off information and all the involved airport arrivals and departure times. The data comes from the various airlines and airports. The Flight Time Table API is used by various clients, such as travel booking agencies.

Functional requirements

  • Given a flight number, the API returns the status and timetable of the flight.

Non-functional requirements

  • High Availability is Critical: The API is used in many business scenarios and should be available 99.95% of the times.

  • Real-Time Response Time is Critical: The API should respond to the clients immediately in the order of milliseconds.

  • Robustness is Critical: The API should be immune against the failure of the back-end data providers. Some back-end data source providers may be disconnected in a specific query time.

  • High Throughput is Important: The Flight Time Table API should be able to handle up to 15,000 requests per second.

System/Platform A Flight Data Platform
API Name The Flight Time Table API
Type of API Public (Open) Web API
Functionality/Data Provided by the API Informing the clients of the schedule of a given flight
Important Requirements (1) Availability of the API is critical.
(2) Response time of the API is critical.
(3) Robustness of the API is critical.
(4) Throughput of the API is important.
1 Question: The Flight Time Table API should respond to numerous clients in real-time (or timely manner). Design a mechanism that helps minimize the response time of the Flight Time Table API?
Question Topic: Response Time [API]
RAPID’s Answer: (a) Caching responses of API or (b) Caching and Maintaining Connections to Back-end services.
For caching responses use: Either (a) Caching most frequent responses or (b) Caching most recent responses, or (c) Caching most probable Reponses.
For caching and maintaining connections to the back-end services use: Connection pooling.
Rating: Acceptable Identical: 5, Acceptable Alternative: 2
Status: Acceptable
2 Question: Back-end data sources of the Flight Time Table [API] may anyway become unavailable momentarily. Design a mechanism that helps the Flight Time Table API manage the situations when the back-end systems cannot respond to the clients.
Question Topic: Failure Recovery [API]
RAPID’s Answer: Provide fall backs: Either (a) Return Empty Responses or (b) Return Cached Responses.
Rating: Acceptable Alternative: 2, Partly Unacceptable: 4, Unacceptable: 1
Status: Unacceptable *
3 Question. How to protect the Flight Time Table API from denial of service failures that might occur due to congestion in the traffic of clients’ requests?
Question Topic: Congestion Control [API]
RAPID’s Answer: (a) Concurrent Rate Limit or (b) Spike Arrest.
Rating: Acceptable Identical: 3, Acceptable Alternative: 3, Partly Unacceptable: 1
Status: Acceptable
4 Question: How to meet 99.95% uptime?
Question Topic: Availability [API]
RAPID’s Answer: Back-end Service Replication.
Rating: Acceptable Identical: 2, Acceptable Alternative: 2, Partly Unacceptable: 1, Insufficient Information: 1, Don’t Know: 1
Status: Acceptable

A social network platform-the friends API

API specification

The Friends API provides the list of friends of a given user to the third-party clients. The API is protected and provides service to partner businesses and enterprise.

Three possible use cases of the Friend API are as follows: (a) to advertise or recommend the products that a user buy to the friends of the user; (b) to show what friends are watching or buying on a web site; (c) to use a third-party service to search within the list of the friends of a user.

Functional requirements

  • Given a users’ name or ID, the API provides the list of the friends of the user.

  • The client may require access the friends list of a user more than one. The client may want to be notified of new friends, when a friend is added.

Non-functional requirements

  • Access Confidentiality is Very Critical: The Friends API should only be accessible to authorized clients.

  • Privacy is Very Critical: Friends data is private and belongs to the user. The confidentiality of the friend data is highly important and must be preserved. The Friends API should not allow access to a user’s data without the consent of data owner. The API must not reveal the user’s data to unwanted audience.

  • Short Latency is Critical: The API should respond to the clients’ request in a timely manner.

System/Platform A Social Network Platform
Name The Friends API
Type of API Protected (Partner to Partner) Web API
Functionality/Data Provided by the API Providing users’ friends List
-Providing more than once access to the clients
Important Requirements (1) Privacy of the API is very critical.
(2) Access Confidentiality of the API is very critical.
(3) Latency of the API is critical.
1 Question: How to protect the privacy of the end-user’s data upon clients’ access to the Friends API. Consider the case that the client may need more than once access to the Friends API.
Question Topic: Privacy [API]
RAPID’s Answer: (a) End-User’s Notification and Approval Upon API Access or (b) Data Masking.
Rating: Acceptable Identical: 1, Acceptable Alternative: 2, Partly Unacceptable: 1, Unacceptable: 2, Don’t Know: 1
Status: Unacceptable *
2 Question: Design an access authorization mechanism for the Friends API. Consider the case that the client may need more than once access to the Friends API.
Question Topic: Access Authorization [API]
RAPID’s Answer: Either (a) Username and Password or (b) Open Authorization Version 2.0.
Rating: Acceptable Identical: 2, Partly Unacceptable: 2, Insufficient Information: 1, Don’t Know: 2
Status: Unacceptable *

A social network platform-the filter and track posts API

API specification

  • The Track Posts API notifies the clients of the users’ posts in which they are interested.

  • One use case of the Track Posts API is to fetch users’ posts with certain keywords from the social network platform and show the messages on a third-party application or web site. For example, posts which contain the name of a product.

Functional requirements

  • The API sends the posts of certain topics to the clients who are interested in that topic.

Non-functional requirements

  • Low Latency is important: Real-Time notification of the clients of a post of interest is important.

  • Reliability is important: The Filter and Track Posts API should guarantees notifying the client of new updates, meaning that if any new status is posted in which a client is interested, they client will be notified of the new post.

System/Platform A Social Network Platform
API Name The Filter and Track Posts API
Type of API Public (Open) Web API
Functionality/Data Provided by the API Informing the clients of posts in which they are interested.
Important Requirements (1) Latency of the API is important.
(2) Reliability of the API is important.
1 Question: How should the Filter and Track Post API notify the clients of the posts in which they are interested?
Question Topic: Communication Style [API]
RAPID’s Answer: Publish and Subscribe
Rating: Acceptable Identical: 5, Partly Unacceptable: 1, Unacceptable: 1
Status: Acceptable

Rights and permissions

Reprints and Permissions

About this article

Verify currency and authenticity via CrossMark

Cite this article

Sadi, M.H., Yu, E. RAPID: a knowledge-based assistant for designing web APIs. Requirements Eng (2021). https://doi.org/10.1007/s00766-020-00342-0

Download citation

Keywords

  • Non-functional requirements
  • Software design and architecture
  • Search-based software engineering
  • Recommendation systems
  • Chatbots
  • Knowledge-based question answering
  • Automated design generation