Downloads On-Demand from the Cessing) Description of Each Endpoint, Which Server

Home , RAML (software), Swagger (software)

Моделі та засоби систем баз даних і знань

UDC 004.724, 004.62 https://doi.org/10.15407/pp2018.04.059

Kyrylo Malakhov, Aleksandr Kurgaev, Vitalii Velychko

MODERN RESTFUL API DLS AND FRAMEWORKS FOR RESTFUL WEB SERVICES API SCHEMA MODELING, DOCUMENTING, VISUALIZING

The given paper presents an overview of modern RESTful API description languages (belongs to interface description languages set) – OpenAPI, RAML, WADL, Slate – designed to provide a structured description of a RESTful web APIs (that is useful both to a human and for automated machine processing), with related RESTful web API modelling frameworks. We propose an example of the schema model of web API of the service for pre-trained distributional semantic models (word embedding’s) processing. This service is a part of the “Personal Research Information System” services ecosystem – the “Research and Development Workstation Environment” class system for supporting research in the field of ontology engineering: the automated building of applied ontology in an arbitrary domain area as a main feature; scientific and technical creativity: the automated preparation of application documents for patenting inventions in Ukraine. It also presents a quick look at the relationship of Service-Oriented Architecture and Web services as well as REST fundamentals and RESTful web services; RESTful API creation process. Key words: Service-Oriented Architecture, Web service, REST, RESTful API, OpenAPI, RAML, WADL, Slate.

Introduction Databases, web sites, business applica- tivity: the automated preparation of applications and services need to exchange data. This tion documents for patenting inventions in is accomplished by defining standard data Ukraine) with related RESTful web API formats such as Extensible Markup Language modelling frameworks. (XML) or JavaScript Object Notation (JSON), as well as transfer protocols or Web Service-Oriented Architecture style services such as the Simple Object Access and Web services Protocol (SOAP) or the more popular today – According to the Open Group [3] (a Representational State Transfer (REST). De- global consortium that develops open, ven- velopers often have to design their own Ap- dor-neutral information technology stand- plication Programming Interfaces (APIs) to ards), an SOA is an architectural style that make applications work while integrating supports service orientation. Service orienta- specific business logic around operating sys- tion is a way of thinking in terms of the out- tems, or servers. This paper introduces these comes of services, and how they can be de- concepts with a focus on the RESTful APIs veloped and combined. In this definition, a and presents an overview of modern RESTful service is a repeatable business activity that API description languages (RESTful API can be logically represented; the Open Group DLs): OpenAPI Specification, RAML, and gives the examples: “check customer credit,” the example of modeling the schema of web and “provide weather data.” Further, a service API of the service for pre-trained distribu- is self-contained, may be composed of other tional semantic models (word embeddings) services, and consumers of the service treat processing (is a part of the “Personal Re- the service as a black box. SOA is a distinct search Information System” [1] services eco- architectural style which is a major improve- system – the “Research and Development ment over earlier ideas, although it includes Workstation Environment” [2] class system some of the earlier ideas. Also, traditional ar- for supporting research in the field of ontolo- chitectural methods must be employed in or- gy engineering: the automated building of ap- der to obtain maximum benefit from using plied ontology in an arbitrary domain area as SOA. a main feature; scientific and technical crea- © Kyrylo Malakhov, Aleksandr Kurgaev, Vitalii Velychko, 2018 ISSN 1727-4907. Проблеми програмування. 2018. № 4 59 Моделі та засоби систем баз даних і знань Another definition of Service-Oriented Figure 1 uses a Venn diagram to illus- Architecture comes from [4]: a paradigm for trate the relationship between SOA and Web organizing and utilizing distributed capabili- services. The overlapping area in the center ties that may be under the control of different represents SOA using Web services for con- ownership domains. It provides a uniform nections. The nonoverlapping area of Web means to offer, discover, interact with and use services represents that Web services can be capabilities to produce desired effects con- used for connections, but connections alone sistent with measurable preconditions and ex- do not make for an SOA. The non- pectations. According to [4], the focus of overlapping area of SOA indicates that an SOAs is to perform a task (business function). SOA can use Web services as well as connec- This is different from some other paradigms, tions other than Web services (the original such as object-oriented architectures, where specifications of CORBA and DCOM are ex- the focus is more on structure of the solution amples). in the case of an object-oriented architecture, the focus is on how to package data inside an object. SOAs address ownership boundaries through service descriptions and service interfaces. SOA provides reuse of externally developed frameworks by providing easy in- teroperability between systems. Generally speaking, in order to perform a task, an SOA groups services on different systems, possibly running on different operating systems, possibly written using different programming languages. Most current SOA-based applications employ an asynchronous client/server-type architectural style – asynchronous event- Figure 1. Relationship of Web services driven architectural style [5]. Event-driven and SOA

SOA (also known as SOA 2.0) is the current Key to SOA is the identification and and advanced form of SOA. In this approach design of services. The idea is that services at present, unlike the older SOA approach should be designed in such a way that they where services used to be designed as pre- become components that can be assembled in defined processes, the events generally trigger multiple ways to support or automate business the execution of activities. The asynchronous functions. It is not necessarily easy to proper- event-driven architectural style is better for ly identify and design services. When done real time or proactive systems, since business well, the services allow an organization to processes are treated as a sequence of events, quickly assemble services – or modify the as- and therefore different business processes that sembly of services – of add or modify the sup- have little relationship with each other, except port or automation of business functions. Here for a few individual shared tasks, do not have are basic concepts related to services [8]. to obey the same kind of centralized man- agement. In an asynchronous event-driven  Atomic service. An atomic service architecture, an event message carries a state is a well-defined, self-contained function that change to an event server. The event server does not depend on the context or state of passes these events along to the servers, pos- other services. Generally, an atomic service sibly with value added. Servers may then would be seen as fine grained or having a fin- generate messages for other event servers (of- er granularity. ten calls “publish/subscribe” architecture).  Composite service. A composite More detailed in-depth look at the current service is an assembly of atomic or other state of SOA presented in [6, 7]. composite services. The ability to assemble

60 Моделі та засоби систем баз даних і знань services is referred to as composability. Com- He coined the term “REST” an architectural posite services are also referred to as com- style for distributed hypermedia systems. Put pound services. Generally, a composite ser- simply, REST (short for Representational vice would be seen as coarse grained or hav- State Transfer) is an architectural style de- ing a larger granularity. fined to help create and organize distributed  Loosely coupled. This is a design systems. The key word from that definition concept where the internal workings of one should be “style,” because an important as- service are not “known” to another service. pect of REST is that it is an architectural style All that needs to be known is the external be- – not a guideline, not a standard, or anything havior of the service. This way, the underly- that would imply that there are a set of hard ing programming of a service can be modified rules to follow in order to end up having a and, as long as external behavior has not RESTful architecture. changed, anything that uses that service con- The RESTful architectural style con- tinues to function as expected. This is similar sists of constraints on data, constraints on the to the concept of information hiding that has interpretation of data, constraints on compo- been used in computer science for a long nents, and constraints on connectors between time. components. The RESTful architectural style pos- The design challenge is to find a bal- sesses the following constraints [9]. ance between fine-grained and coarse-grained services to minimize communication over- Client-Server. The separation of con- head yet keep the services loosely coupled. cerns is the core theme of the Web’s client- Services are assembled to support or server constraints. The Web is a client-server- automate business functions. Figure 2 illus- based system, in which clients and servers trates the assembly of services. This repre- have distinct parts to play. They may be im- sents an SOA. Web services are used to con- plemented and deployed independently, using nect the services in an SOA [8]. any language or technology, so long as they conform to the Web’s uniform interface. Services Stateless. The client-server interaction is stateless. There is no stored context on the Web services server. Any session information must be kept by the client. Cacheable. Data in a response (a response to a previous request) is labeled as cacheable or non-cacheable. If it is cacheable, the client (or an intermediary) may reuse that Figure 2. Assembly of services into an SOA for the same kind of request in the future. It is easy to imagine that we can reas- Caching response data can help to reduce cli- semble the same services with other services ent-perceived latency, increase the overall to achieve a different functionality. This abil- availability and reliability of an application, ity to change the assembly of services is one and control a web server’s load. In a word, way that an SOA can quickly adapt to chang- caching reduces the overall cost of the Web. ing business needs. Uniform Interface. There is a uniform interface between components. In practice, RESTful architectural style and there are four interface constraints: resource RESTful web services identification – requests identify the resources they are operating on (by a URI, for exam- According to Fielding [9], the REST- ple); resource manipulation through the repre- ful architectural style focuses on: “...the roles sentation of the resource – when a client or of components, the constraints upon their in- server that has access to a resource, it has teraction with other components, and their enough information based on understanding interpretation of significant data elements...”.

61 Моделі та засоби систем баз даних і знань the representation of the resource to be able to (API User Experience) should be a primary modify that resource; messages are self- concern in API development. descriptive – the message contains enough The process of RESTful API creation information to allow a client or server to han- must contain all of the following steps: dle the message, this is normally done  Determining business value. through the use of Internet Media types  Choosing metrics. (MIME types); use of hypermedia to change the state of the application – for example, the  Defining use cases. server provides hyperlinks that the client uses  Designing API and creating a to make state transitions. schema model. Layered System. Components are or- A detailed description of the RESTful ganized in hierarchical layers; the compo- API creation process is presented in [8, 10, nents are only aware of the layer within which 11]. In our paper we will focus on the design- the interaction is occurring. Thus, a client ing API and creating a schema model. Model- connecting to a server is not aware of any in- ing the schema for your API means creating a termediate connections. design document that can be shared with oth- Code-on-Demand. The Web makes er teams, customers, or executives. A schema heavy use of code-on-demand, a constraint model is a contract between your organization which enables web servers to temporarily and the clients who will be using it. A schema transfer executable programs, such as scripts model is essentially a contract describing or plug-ins, to clients. Code-on-demand tends what the API is, how it works, and exactly to establish a technology coupling between what the endpoints are going to be. Think of it web servers and their clients, since the client as a map of the API, a user-readable and a must be able to understand and execute the machine-readable (automated machine pro- code that it downloads on-demand from the cessing) description of each endpoint, which server. For this reason, code-on-demand is the can be used to discuss the API before any only constraint of the Web’s architectural code is written. With a schema model, we can style that is considered optional. ensure that everyone has a shared understanding of what the API will do and how each re- So, it’s pretty clear that the RESTful source will be represented when the API is web services meet the constraints of the complete. Each of the schema modeling lan- RESTful architecture. Summarizing, a REST- guages has tools available to automate testing ful web service is client/server-based, does or code creation based on the schema model not store state. It accesses resources (web you’ve created. But even without this func- pages or data) located at a URL. The results tionality, the schema model helps us have a of a request from client to server can be solid understanding of the API before a single cached in the client. It has a uniform interface line of code is written. Figure 3 shows the with self-descriptive messages, based on hy- API Modeling framework where you have permedia. Also, the client and server aren’t API specifications defined and generate API aware of intermediate connections between documentation [12]. Also, generate server and the two of them. client source code. RESTful API creation process – Next, we’ll look at the specifics of two of the main schema modeling frameworks and designing API and creating markup languages: a schema modeling . RESTful API Modeling Language As UI is to UX (User Experience), (RAML), which supports Markdown. API is to APX (Application Programming . OpenAPI specification (OpenAPI) Experience). Like optimizing for UX (User format (previously Swagger), which supports Experience) has become a primary concern in JSON and YAML. UI development, also optimizing for APX

62 Моделі та засоби систем баз даних і знань

Client Gen Source erat e AP I spe cific ation REST client Gen erate clie Generate nt so urce JSON, API documentation on HTML ntati YAML ume doc API erate Gen urce API API er so serv specification documentation, erate Server Gen (machine-readable) visualising Source (human-readable)

RESTful Web service

Figure 3. API modelling

RAML and OpenAPI: an overview maintain; strong, visual-based integrated development environment and online tooling The RESTful API Modeling Language with collaboration focus; allows for design (RAML) [13] is a concise, expressive lan- patterns; easy to get started. Cons: lacks guage for describing RESTful APIs. Built on strong documentation and tutorials outside of broadly used standards such as YAML specification; limited code reuse/extensions; (YAML stands for Yet Another Markup Lan- multiple specifications required for several guage, and is a generic specification lan- tools, including dev and QA; poor tooling guage) and JSON, RAML is a non-prop- support for newer versions. rietary, vendor-neutral open spec. RAML was The best way to get started with created around the notion of design-first de- RAML is to use the RAML API Designer velopment [12]. Although all of the specifica- with free account on the Anypoint system, tion languages can be used this way, RAML where MuleSoft maintains its RAML specif- was designed this way from the outset. It ic tools [17]. RAML excels at supporting the makes it easy to create a code development entire API's lifecycle. It provides a balance life cycle that supports the development of between developer tooling and technical APIs that meet your business goals and use writers without taking away from one or the cases. The RAML website [14] has good doc- other. It also is the fastest framework to umentation, including strategies, best practic- ramp up your project. MuleSoft maintains es, and practical instruction. You’ll find a some open source tools that can extend and basic tutorial for the RAML language itself at improve experience with a RAML specifica- [14]. RAML has good online modeling tools, tion. The API Designer that helps you design also, it has been open-sourced along with your schema from the ground up. An API tools and parsers for common languages. The Console graphical user interface is available development of RAML will be overseen by a that displays the structure and patterns and steering committee of API and UX practition- creates interactive documentation. The API ers, and there is an emerging ecosystem of Notebook provides a way to use JavaScript third-party tools being developed around to test and explore APIs and create Mark- RAML [15]. Consider the pros and cons of down versions of the API to share on RAML [16]. Pros: single specification to GitHub. You’ll find hundreds of additional

63 Моделі та засоби систем баз даних і знань RAML tools at GitHub and on the [13] web- Both languages are strong and able site, which can help you create and leverage to produce excellent APIs despite their dif- the schemas you build. ferences. Their key differences are what can The OpenAPI Specification OpenAPI, help you determine which is best for your originally known as the Swagger Specifica- business. tion, is a specification for machine-readable OpenAPI’s best features are its strong interface files for describing, producing, con- documentation and compatibility with lesser suming, and visualizing RESTful web ser- used languages. It provides a fast setup and a vices. Originally part of the Swagger frame- large support community. The big takeaway work [18], it became a separate project in for OpenAPI is that it is designed as a bot- 2016, overseen by the OpenAPI Initiative, an tom-up specification. OpenAPI specifies the open source collaborative project of the Linux behavior which affects the API to create more Foundation [19]. Swagger and some other complex, interlocking systems. tools can generate code, documentation and RAML excels at supporting the entire test cases given an interface file. OpenAPI API’s lifecycle. It provides a balance between was one of the earliest schema modeling developer tooling and technical writers with- frameworks available, and it has gone through out taking away from one or the other. It also a few revisions. Version 3.0 is the most recent is the fastest framework to ramp up your pro- one as of this writing. During the develop- ject. The main difference between the two is ment of the various versions, they’ve incorpo- that RAML is a top-down specification, rated many of the best practices uncovered by meaning it breaks down the system and ex- the other two languages, and OpenAPI re- plains the behavior of the various sub- mains one of the innovative frameworks components. available. OpenAPI supports both JSON and The main characteristics of both YAML for its schema markup. Consider the RESTful API DLs are presented in the com- pros and cons of OpenAPI [16]. Pros: a large parative table. community and support-base; high adoption There are, of course, alternatives. Two rate, meaning lots of documentation; strong of the most popular are WADL [20] and Slate framework support; has the largest language [21]. Each have their own caveats, of course. support of any opensource framework. Cons: WADL is incredibly time consuming to create requires multiple specifications for some descriptions with, and the linking methodolo- tools, including dev and QA; doesn't allow for gy leaves much to be desired when compared code reuse, includes, or extensions; lacks to any of the three specifications discussed strong developer tools; requires schemas for throughout this article. Slate, similarly, has all responses. the caveat of having untested or unproven ap- OpenAPI has a very strong modeling proaches due to the relatively small userbase, language for defining exactly what’s expected despite the fact that it handles documentation of the system – very useful for testing and much like API Blueprint [22] does, and gen- creating coding stubs for a set of APIs. erates a pretty interface for it all. In comparison to one another, both These alternatives are interesting, to OpenAPI and RAML are very capable, com- be sure, but their low adoption rates, issues patible with many languages. inherent to their structure, and fundamental . Both offer compatibility in: .NET, caveats make a potentially unstable bet. With Go, Haskell, Java, JavaScript, Node.js, PHP, many strategies in the modern IT workforce Python, Ruby, Scala. focusing heavily on rapid development and deployment, untested approaches have the . OpenAPI’s additional capabilities: distinct possibility of massively lowered qual- Clojure, Coldfusion, D, Eiffel, Erlang, ity as the demand rises exponentially. Groovy, and Typescript. As part of the development of the . RAML's additional capabilities: “Personal Research Information System” Elixer and Pearl. [1, 2], the API schemas of its services was

64 Моделі та засоби систем баз даних і знань Table. Сomparison of modern RESTful API DLs and frameworks

Description RAML OpenAPI WADL Slate Language

Software Apache 2.0 Apache 2.0 CDDL 1.1 Apache 2.0 license YAML Format YAML, JSON XML Markdown (Markdown)

Open source yes yes yes yes

Commercial yes yes no no offering

Mulesoft, Cisco, Open API Initia- Sponsored by VMware, Paypal, tive, Google, IBM, Oracle - AngularJS, Box Mcrosoft

Current release 1.0 3.0 - 2.3.1

Design API-first Existing API Existing API Existing API strategy https://github.com https://github.com References http://raml.org http://swagger.io /javaee/wadl /lord/slate

Code yes yes no no generation

Documentation yes yes yes yes

Visual-based yes yes no yes IDE

Online IDE yes yes no no

API Workbench Swagger Tools Editors (IDE based on (editor, codegen, no Local web editor Atom) UI) modeled with OpenAPI, in particular, the terms, words) within the chosen DSM; find schema model of web API of the service for the center of lexical cluster for a set of terms pre-trained distributional semantic models (including multiple-word terms, one-word (word embeddings) (DSM) processing. With terms, words) within the chosen DSM; calcu- this web service API is possible to: calculate late semantic similarity between two sets of semantic similarity between pair of terms (in- terms (including multiple-word terms, one- cluding multiple-word terms, one-word terms, word terms, words) within the chosen DSM. words) within the chosen DSM; compute a The source code and the service API list of nearest semantic associates for terms schema model description are available via (including multiple-word terms, one-word GitHub repository [23].

65 Моделі і засоби систем баз даних та знань Conclusion https://www.oasis-open.org/committees/ download.php/19679/soa-rm-cs.pdf [Ac- OpenAPI as well as RAML have very cessed: 05.11.2018] much in common. Projects relying on the ex- 5. Chou D. Using Events in Highly Distributed tensive language support and tool integrations Architectures. The Architecture Journal. [On- will tend to OpenAPI. But if the language line] Available from: https://msdn.microsoft. support is not crucial as implementations are com/en-us/library/ dd129913.aspx [Accessed: foremost done in standard languages such as 05.11.2018] Java, RAML is an equivalent option. OpenA- 6. Bhowmik S. Cloud Computing. Cambridge PI and RAML both have a large community University Press. 2017. 462 p. and are backed by market leaders, so it will 7. Etzkorn L.H. Introduction to Middleware: never be wrong choosing one of them for API Web Services, Object Components, and Cloud documentation. Computing. CRC Press, 2017. 662 p. 8. Barry D.K. Web Services, Service-Oriented Recently, several APIs contributors Architectures, and Cloud Computing: The (members of 3Scale, Apigee, Capital One, Savvy Manager’s Guide. Morgan Kaufmann Google, IBM, Intuit, Microsoft, PayPal, is an imprint of Elsevier, 2013. 248 p. Restlet and SmartBear) have announced the 9. Fielding R. 2000. Architectural Styles and the Open API Initiative [19], which aims at Design of Network-Based Software Architec- standardizing the way REST APIs are de- tures. Ph.D. Disser- tation, University of Cali- scribed. This initiative will extend the Swag- fornia-Irvine. [Online] Avaliable from: ger specification and format to create an open https://www.ics.uci.edu/~fielding/pubs/dissert technical community where members can eas- ation/top.htm [accessed 05.11.2018] ily contribute to building a vendor-neutral, 10. Pereira C.R. Building APIs with Node.js. portable and open specification for providing Apress, 2016. 135 p. 11. Doglio F. REST API Development with metadata for RESTful APIs. We hope this Node.js. Apress, 2018. 323 p. initiative will also promote and facilitate the 12. Patni S. Pro RESTful APIs: Design, Build and adoption and use of a standard API Descrip- Integrate with REST, JSON, XML and JAX- tion Language. RS. Apress, 2017. 126 p. 13. RESTful API Modeling Language (RAML). [Online] Available from: https://raml.org/ [Accessed: 05.11.2018] References 14. RAML 100 Tutorial | RAML. [Online] Avail- able from: https://raml.org/developers/raml- 100-tutorial [Accessed: 05.11.2018] 1. Palagin O.V., Velychko V.Yu., Malakhov 15. API Design Tooling From RAML. [Online] K.S. and Shchurov O.S. Personal research in- Available from: formation system. About developing the http://apievangelist.com/2014/ 03/01/api- methods for searching patent analogs of in- design-tooling-from-raml/ [Accessed: vention. Computer means, networks and sys- 05.11.2018] tems. 2017. N 16. P. 5–13. (in Ukrainian). 16. Swagger (OAS) vs. RAML - Which is Better 2. Palagin O.V., Velychko V.Yu., Malakhov for Building APIs? [Online] Available from: K.S. and Shchurov O.S. (2018). Research and https://blog.vsoftconsulting.com/blog/is-raml- development workstation environment: the or-swagger-better-for-building-apis [Ac- new class of current research information sys- cessed: 05.11.2018] tems. Problems in programming. N 2–3. P. 17. Anypoint Platform. [Online] Available from: 289–298. https://anypoint.mulesoft.com/ [Accessed: 3. Open Group. Service Oriented Architecture: 05.11.2018] What is SOA? [Online] Available from: 18. The Best APIs are Built with Swagger Tools | https://www.opengroup.org/soa/source-book/ Swagger. [Online] Available from: soa/p1.htm [Accessed: 05.11.2018] https://swagger.io/ [Accessed: 05.11.2018] 4. Mackenzie C.M., Laskey K., McCabe F., 19. OpenAPI Initiative Charter. [Online] Availa- Brown P.F., Metz R. 2006. OASIS Reference ble from: https://www.openapis.org/partici- Model for Service Oriented Architecture 1.0. pate/how-to-contribute/governance [Ac- OASIS. [Online] Available from: cessed: 05.11.2018]

66 Моделі і засоби систем баз даних та знань 20. Web Application Description Language. 9. Fielding R. 2000. Architectural Styles and the [Online] Available from: https://www.w3.org/ Design of Network-Based Software Architec- Submission/wadl/ [Accessed: 05.11.2018] tures. Ph.D. Disser- tation, University of Cali- 21. Lord/slate: Beautiful static documentation for fornia-Irvine. [Online] Avaliable from: your API. [Online] Available from: https://www.ics.uci.edu/~fielding/pubs/dissert https://github.com/lord/slate [Accessed: ation/top.htm [accessed 05.11.2018] 05.11.2018] 10. Pereira C.R. Building APIs with Node.js. 22. API Blueprint | API Blueprint. [Online] Apress, 2016. 135 p. Available from: https://apiblueprint.org/ [Ac- 11. Doglio F. REST API Development with cessed: 05.11.2018] Node.js. Apress, 2018. 323 p. 23. Malakhovks/ds-rest-api. GitHub. [Online] 12. Patni S. Pro RESTful APIs: Design, Build and Available from: https://github.com/mala- Integrate with REST, JSON, XML and JAX- khovks/ds-rest-api [Accessed: 05.11.2018] RS. Apress, 2017. 126 p. 13. RESTful API Modeling Language (RAML). [Online] Available from: https://raml.org/ [Accessed: 05.11.2018] 14. RAML 100 Tutorial | RAML. [Online] Avail- Література able from: https://raml.org/developers/raml- 100-tutorial [Accessed: 05.11.2018] 15. API Design Tooling From RAML. [Online] 1. Палагін О.В., Величко В.Ю., Малахов К.С., Available from: Щуров О.С. Автоматизоване робоче місце http://apievangelist.com/2014/ 03/01/api- наукового дослідника. До питання розроб- design-tooling-from-raml/ [Accessed: ки методів пошуку аналогів патентної до- 05.11.2018] кументації винаходу. Комп'ютерні засоби, 16. Swagger (OAS) vs. RAML - Which is Better мережі та системи. 2017. № 16. С. 5–13. for Building APIs? [Online] Available from: 2. Palagin O.V., Velychko V.Yu., Malakhov https://blog.vsoftconsulting.com/blog/is-raml- K.S. and Shchurov O.S. (2018). Research and or-swagger-better-for-building-apis [Ac- development workstation environment: the cessed: 05.11.2018] new class of current research information sys- 17. Anypoint Platform. [Online] Available from: tems. Problems in programming. N 2–3. https://anypoint.mulesoft.com/ [Accessed: P. 289–298. 05.11.2018] 3. Open Group. Service Oriented Architecture: 18. The Best APIs are Built with Swagger Tools | What is SOA? [Online] Available from: Swagger. [Online] Available from: https://www.opengroup.org/soa/source-book/ https://swagger.io/ [Accessed: 05.11.2018] soa/p1.htm [Accessed: 05.11.2018] 19. OpenAPI Initiative Charter. [Online] Availa- 4. Mackenzie C.M., Laskey K., McCabe F., ble from: https://www.openapis.org/partici- Brown P.F., Metz R. 2006. OASIS Reference pate/how-to-contribute/governance [Ac- Model for Service Oriented Architecture 1.0. cessed: 05.11.2018] OASIS. [Online] Available from: 20. Web Application Description Language. https://www.oasis-open.org/committees/ [Online] Available from: https://www.w3.org/ download.php/19679/soa-rm-cs.pdf [Ac- Submission/wadl/ [Accessed: 05.11.2018] cessed: 05.11.2018] 21. Lord/slate: Beautiful static documentation for 5. Chou D. Using Events in Highly Distributed your API. [Online] Available from: Architectures. The Architecture Journal. [On- https://github.com/lord/slate [Accessed: line] Available from: https://msdn.microsoft. 05.11.2018] com/en-us/library/ dd129913.aspx [Accessed: 22. API Blueprint | API Blueprint. [Online] 05.11.2018] Available from: https://apiblueprint.org/ [Ac- 6. Bhowmik S. Cloud Computing. Cambridge cessed: 05.11.2018] University Press. 2017. 462 p. 23. Malakhovks/ds-rest-api. GitHub. [Online] 7. Etzkorn L.H. Introduction to Middleware: Available from: https://github.com/mala- Web Services, Object Components, and Cloud khovks/ds-rest-api [Accessed: 05.11.2018] Computing. CRC Press, 2017. 662 p. 8. Barry D.K. Web Services, Service-Oriented Architectures, and Cloud Computing: The Savvy Manager’s Guide. Morgan Kaufmann is an imprint of Elsevier, 2013. 248 p. Data received 20.09.2018

67 Моделі і засоби систем баз даних та знань About the authors: Vitalii Velychko, PhD, assistant professor, Senior researcher. Kyrylo Malakhov, 73 Ukrainian publications, Junior Research Fellow. 25 International publications, 38 Ukrainian publications, H-index: Google Scholar – 7, Scopus – 1. 3 International publications, http://orcid.org/0000-0002-7155-9202. H-index: Google Scholar – 4. http://orcid.org/0000-0003-3223-9844. Affilation:

Aleksandr Kurgaev, V.M. Glushkov Institute of cybernetics of Doctor of Technical Science, National Academy of Sciences of Ukraine, Professor, Leading Researcher of Department 40 Glushkov ave., Kyiv, 205 at Glushkov Institute of Cybernetics. Ukraine, 03187. Author of more than 240 scientific works, Phone: (+38) (044) 526 3348. including 8 monographs, Email: [email protected] 100 Patents and Author’s Certificates for innovations and useful models. H-index: Google Scholar – 5, Scopus – 2. http://orcid.org/0000-0001-5348-2734.