Rikkalike uuenduste avaldamine käskluste kaudu REST APIs

Date

2017

Journal Title

Journal ISSN

Volume Title

Publisher

Abstract

Paari viimase aastaga on Representational State Transfer (REST) muutunud Application Programming Interface’i (API) disaini liidriks tänu lihtsusele ja mitmekülgsusele. See on hõlbustanud API’sid URL’ide juures, mis kasutavad selliseid HTTP meetodeid nagu GET, POST, PUT ja DELETE. See on viinud lihtsustatud mudelite toomiseni klientide tarkvara arendajatele. Siiski on kaks probleemi, mida REST ainuüksi ei lahenda. Esimene neist on standardiseeritud vastused. Enamikel ettevõtetest on oma API’d, tavaliselt JSON tüüpi vastusega, mis ühtib nende andmemudeliga. Hea näide on see, kui Twitter’i API klient ei ole võimeline otseselt ühendust võtma Reddit API’ga ja vastupidi. Seetõttu teevad paljud API kliendid peaaegu sama asja. Sellest tulenevalt leiame me olukorra, kus arvukad arendajad kordavad sedasama saavutust. Järgmine probleem on API’de sidumine. World Wide Web’i Consortsium’i (W3C) kohaselt JSON ei sisalda sisseehitatud toetust hüperlinkidele, mis moodustavad põhilise Web’i ehitusbloki. Nende kahe puudused tähendavad seda, et API lõpp-punktid on seotud API dokumentatsiooniga, seega on kasutajad sunnitud hoolikalt läbi lugema mitmeid lehekülgi API dokumentatsioone, et mõista API lõpp-punktide vahelist suhet ning saada aru, mis tegevused on vajalikud juurdepääsuks antud vahendile. Kokkuvõttes me näeme, et kaasaegsetel rakendustel, arendatud API’d, on uuenduste käsklused ühendatud meetoditega, mis manipuleerivad otseselt domeeniga. Selles uuringus arutleme uuendusi otsivate käskluste probleemi üle ja püüame leida võimalusi, et täiustada seda rikkalike uuendusmeetodite ja erinevaid lähenemisi kasutavate, uuendusi otsivate, käskluste kaudu. Esimese panusena selles uurimustöös, tuleb võtta hüpermeedia formaat Collection +JSON ja parendada seda nii, et see mahutaks rohkem uuenduste käsklusi läbi üheainsa REST uuenduse meetodi dünaamiliselt nii API’s kui kliendi tarkvaras. Lihtsalt öeldes me kooskõlastame REST’i lihtsuse Domain Driven Development and Command Query Responsibility Segregation’i (CQRS) rikkalike kontseptidega. Me loome märkustel põhineva ressursi pakkija, mis genereerib käsud dünaamiliselt kasutades jagatud kontrollijat ja liidest, mis vähendab koodi, mida vajatakse laadimisel valdkonna teenuse meetodina API’sse.
In the past few years Representational State Transfer (REST) has emerged a leader of modern Application Programming Interface (API) design for its simplicity and versatility. This has facilitated APIs with URLs that make use of HTTP methods like GET, POST, PUT and DELETE. It has also led to producing intuitive models for client developers. However, there are two issues that REST doesn’t solve alone, the first issue being standardized responses. Most enterprises have their own custom APIs, usually a JSON response that maps clearly to their custom data model. A good example is when a Twitter API client is not able directly communicate with a Reddit API and vice versa. This leads to numerous API clients that do almost, but not quite the same thing. Hence we find numerous developers duplicating the same efforts. The second issue is linking. As put by the World Wide Web Consortium (W3C): JSON doesn’t include built-in support for hyperlinks, which fundamentally constitutes as a building block on the Web. Hence the drawbacks of the two is that the API endpoints are only linked by API documentation, thus users are forced to peruse through pages of API documentation to comprehend the relationships between the API endpoints and understand what actions are required to interact with a given resource. In summary, we find that in modern day applications, the APIs developed have their update operations mapped to methods that directly manipulate the domain. In this research we discuss the underlying problem with update queries and unearth ways to enhance them for richer update methods and queries using various approaches. The first contribution in this research is to take a hypermedia format namely Collection +JSON, and to enhance it to accommodate and expose multiple update commands and templates through a single REST update method dynamically, both in the API and the client. In simple words, we reconcile the simplicity of REST, with the ample concepts of Domain Driven Development and Command Query Responsibility Segregation (CQRS). We also implement an annotation based resource assembler that generates commands dynamically by using a generic controller and interface that reduces the implementation needed to inject domain service methods into the API.

Description

Keywords

Citation