Table Of ContentModel-Driven Development of REST APIs
Tomás Procházka
Master in Information Systems
Submission date: June 2015
Supervisor: John Krogstie, IDI
Norwegian University of Science and Technology
Department of Computer and Information Science
Abstract
ThedomainofRESTAPIscontainshighlyrepetitivecodewhichneedstobewrittenev-
erytimethereisaneedforanewRESTAPI.Whendevelopingclient-sideapplications,
like web applications or native applications, one must also create a robust REST API in
order to share the data between all the clients. The server-side technology takes a huge
partofthebudgetandinmostcasesitisnotthemainproduct-theclient-sideapplication
is. The author is trying to solve this problem by applying the Model-Driven Develop-
ment paradigm. A code generator specifically designed for the domain is proposed and
developed. ThecodegeneratorhassomeuniquefeaturessuchasGitHubintegrationand
mechanisms to structure the files in the same way as human would do. This has been
achievedbyanalyzingthehumancreatedfilestructure. ThegeneratedRESTAPIcomes
alsowithanoptionofautomaticallytestingbehaviorcomparedtobestpractices. Thisis
donebytakinganexistingsolutionandfurtherresearchingitsuse.
i
Preface
ThisreporthasbeencreatedasadocumentationofmyMasterThesisinInformationSys-
temsattheDepartmentofComputerandInformationScienceattheNorwegianUniversity
ofScienceandTechnology. ThethesishasbeenwrittenincooperationwithSearisAS.
IwouldliketothankmysupervisorprofessorJohnKrogstieforinspiration,patience,
andmainlyalotofusefuladvise. AhugethankyoualsobelongstotheguysfromSearis
AS for their useful comments, evaluation and mainly the smooth cooperation I had with
them. Last but not least to my family since this would not be possible without them. A
specialthankyoualsogoestomygirlfriendLisa,becauseshehadtohandlemeinmoods
shewillhopefullynevereverseemeinagain. IamgladIwasluckyenoughtosurround
myselfwithsuchawesomepeople.
TomasProchazka
ii
Table of Contents
Abstract i
Preface ii
TableofContents v
ListofTables vii
ListofFigures x
Abbreviations xi
1 Introduction 1
1.1 BackgroundandMotivation . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 ResearchQuestions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 ThesisOutline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Background 5
2.1 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 BestPracticesWhenCreatingURIs . . . . . . . . . . . . . . . . 6
2.1.2 HTTPMethods . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 RESTAPINotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 RAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Swagger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3 APIBlueprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.4 JAX-RS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Apiary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Restlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3 ProjectTexo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.4 EMFREST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
iii
2.3.5 WebBasedEditor . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Model-DrivenSoftwareDevelopment . . . . . . . . . . . . . . . . . . . 13
2.4.1 Templatederiving . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.2 Protectedareas . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Codegenerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.1 Acceleo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.2 ProjectMatilda . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Research 17
3.1 DesignScience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 GoalsandRequirements 21
4.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.1 FunctionalRequirements . . . . . . . . . . . . . . . . . . . . . . 22
4.2.2 Non-FunctionalRequirements . . . . . . . . . . . . . . . . . . . 24
5 Implementation 25
5.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.1 NodeJSandNPM. . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.3 MochaJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4 GruntJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.5 UnderscoreJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.6 Dredd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.7 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.8 WhynotJava? . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3 GenerationProcess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3.1 Meta-Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3.3 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3.4 TemplatesLoad . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3.5 TemplatesExecution . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.6 CodeBeautification. . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.7 TemplatesSaver . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.8 Generator’sConfigurationFile . . . . . . . . . . . . . . . . . . . 40
5.3.9 Generator’sEndpoints . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.10 GitIntegrationandVersioning . . . . . . . . . . . . . . . . . . . 42
5.3.11 Download,Installation,RunandTest . . . . . . . . . . . . . . . 44
5.4 RESTAPItemplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.4.1 FolderStructure . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.4.2 FilteringandSorting . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4.3 Behaviorprediction. . . . . . . . . . . . . . . . . . . . . . . . . 46
iv
5.4.4 APIBlueprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5 TemplateDevelopmentWorkflow . . . . . . . . . . . . . . . . . . . . . 47
5.5.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5.2 TemplateDevelopmentProcess . . . . . . . . . . . . . . . . . . 48
5.6 TheEditorExtensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.6.1 Endpointhandling . . . . . . . . . . . . . . . . . . . . . . . . . 50
6 Evaluation 51
6.1 FunctionalRequirements . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1.1 Meta-ModelIndependence . . . . . . . . . . . . . . . . . . . . . 51
6.1.2 PlatformIndependence . . . . . . . . . . . . . . . . . . . . . . . 52
6.1.3 EndpointCompleteness . . . . . . . . . . . . . . . . . . . . . . 53
6.1.4 ModelCompleteness . . . . . . . . . . . . . . . . . . . . . . . . 56
6.1.5 BestPracticeBehavior . . . . . . . . . . . . . . . . . . . . . . . 59
6.1.6 CodeQuality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.1.7 FolderStructureQuality . . . . . . . . . . . . . . . . . . . . . . 63
6.1.8 Re-GeneratingManagement . . . . . . . . . . . . . . . . . . . . 64
6.1.9 TemplateRe-Usability . . . . . . . . . . . . . . . . . . . . . . . 65
6.1.10 OutputTestability. . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2 Non-FunctionalRequirements . . . . . . . . . . . . . . . . . . . . . . . 66
6.2.1 Cross-Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2.2 OutputTestability. . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2.3 TemplateSharing . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2.4 Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7 Discussion 69
8 ConclusionandFutureWork 71
Bibliography 72
AppendixA-StudyCase 75
AppendixB-Videos 84
AppendixC-ExternalAssessment 85
AppendixD-UnitTests 87
v
vi
List of Tables
2.1 ExpectedbehaviorofarequestwithacombinationofamethodandURI . 8
4.1 Functionalrequirements . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Non-functionalrequirements . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1 Comparisonofthemodeledendpointswiththegeneratedones . . . . . . 56
6.2 ExpectedbehaviorrelatedtotheDreddtestresults. . . . . . . . . . . . . 60
vii
viii
Description:The domain of REST APIs contains highly repetitive code which needs to be written ev- ery time there is a REST API. When developing client-side applications, . 5.2.1 NodeJS and NPM . disappear when the generation pro-.
