Bibliografia.bib

@online{mdnapi,
  title={API - MDN Web Docs Glossary: Definitions of Web-related terms | MDN},
  year={2021},
  url={https://developer.mozilla.org/en-US/docs/Glossary/API},
  addendum = "(accessed: 15.02.2022)"
}

@online{mdn,
  title={MDN Web Docs},
  year={2021},
  url={https://developer.mozilla.org/en-US/},
  addendum = "(accessed: 22.02.2022)"
}

@online{graphqlorg,
  title={GraphQL | A query language for your API},
  url={https://graphql.org/},
  year={2021},
  addendum = "(accessed: 22.04.2022)"
}

@online{the-year-graphql-kills-rest,
   title = {52. Is 2018 the year GraphQL kills REST?},
   url = {https://www.stridenyc.com/podcasts/52-is-2018-the-year-graphql-kills-rest},
   year={2018},
   addendum = "(accessed: 22.02.2022)"
}

@online{graphql-intro,
   title = {GraphQL: A data query language - Engineering at Meta},
   author = {Lee Byron},
   year={2015},
   url = {https://engineering.fb.com/2015/09/14/core-data/graphql-a-data-query-language/},
   addendum = "(accessed: 22.02.2022)",
}

@online{RESTfulcookbook,
   title = {- The RESTful cookbook},
   author = {Joshua Thijssen},
   year={2017},
   url = {https://restcookbook.com/},
   addendum = "(accessed: 22.02.2022)"
}

@online{restapitutorial,
   title = {REST API Tutorial},
   url = {https://www.restapitutorial.com/},
}

@online{express,
   title = {Express - Node.js web application framework},
   year={2022},
   url = {https://expressjs.com/},
   addendum = "(accessed: 28.05.2022)"
}

@online{TimBerners-Lee,
   title = {Tim Berners-Lee - Wikipedia},
   year={2022},
   url = {https://en.wikipedia.org/wiki/Tim_Berners-Lee},
}

@online{FactsAboutW3C,
   title = {Facts About W3C},
   year={2021},
   url = {https://www.w3.org/Consortium/facts#history},
   addendum = "(accessed: 22.02.2022)"
}

@article{Brito2020,
   abstract = {GraphQL is a novel query language for implementing service-based software architectures. The language is gaining momentum and it is now used by major software companies, such as Facebook and GitHub. However, we still lack empirical evidence on the real gains achieved by GraphQL, particularly in terms of the effort required to implement queries in this language. Therefore, in this paper we describe a controlled experiment with 22 students (10 undergraduate and 12 graduate), who were asked to implement eight queries for accessing a web service, using GraphQL and REST. Our results show that GraphQL requires less effort to implement remote service queries when compared to REST (9 vs 6 minutes, median times). These gains increase when REST queries include more complex endpoints, with several parameters. Interestingly, GraphQL outperforms REST even among more experienced participants (as is the case of graduate students) and among participants with previous experience in REST, but no previous experience in GraphQL.},
   author = {Gleison Brito and Marco Tulio Valente},
   doi = {10.1109/ICSA47634.2020.00016},
   isbn = {9781728146591},
   journal = {Proceedings - IEEE 17th International Conference on Software Architecture, ICSA 2020},
   keywords = {GraphQL,REST,Web APIs},
   month = {3},
   pages = {81-91},
   publisher = {Institute of Electrical and Electronics Engineers Inc.},
   title = {REST vs GraphQL: A controlled experiment},
   year = {2020},
}

@online{FieldingRThesis,
   author = {Roy Thomas Fielding},
   title = {Architectural Styles and the Design of Network-based Software Architectures},
   year={2000},
   url = {https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm},
   addendum = "(accessed: 22.02.2022)",
}

@online{FieldingRThesisREST,
   author = {Roy Thomas Fielding},
   title = {Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)},
   year={2000},
   url = {https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm},
   addendum = "(accessed: 22.02.2022)",
}

@online{SchemasAndTypes,
   title = {Schemas and Types | GraphQL},
   year={2022},
   url = {https://graphql.org/learn/schema},
   addendum = "(accessed: 07.03.2022)",
}

@online{SchemasAndTypes-objectTypes,
   title = {Schemas and Types | GraphQL},
   year={2022},
   url = {https://graphql.org/learn/schema/#object-types-and-fields},
   addendum = "(accessed: 07.03.2022)",
}

@online{QueriesAndMutations,
   title = {Queries and Mutations | GraphQL},
   year={2022},
   url = {https://graphql.org/learn/queries/},
   addendum = "(accessed: 16.03.2022)",
}

@online{QueriesAndMutations-arguments,
   title = {Queries and Mutations | GraphQL},
   year={2022},
   url = {https://graphql.org/learn/queries/#arguments},
   addendum = "(accessed: 07.03.2022)",
}

@online{graphql-spec,
   title = {GraphQL},
   year={2021},
   url = {https://spec.graphql.org/October2021/#sec-Overview},
   addendum = "(accessed: 07.03.2022)",
}

@online{SpecOverview,
   title = {GraphQL},
   year={2021},
   url = {https://spec.graphql.org/October2021/#sec-Overview},
   addendum = "(accessed: 07.03.2022)",
}

@online{SpecTypes,
   title = {GraphQL},
   year={2021},
   url = {https://spec.graphql.org/October2021/#sec-Types},
   addendum = "(accessed: 07.03.2022)",
}

@online{SpecInterfaces,
   title = {GraphQL},
   year={2021},
   url = {https://spec.graphql.org/October2021/#InterfaceTypeDefinition},
   addendum = "(accessed: 07.03.2022)",
}

@online{SpecUnions,
   title = {GraphQL},
   year={2021},
   url = {https://spec.graphql.org/October2021/#sec-Unions},
   addendum = "(accessed: 07.03.2022)",
}

@online{SpecEnums,
   title = {GraphQL},
   year={2021},
   url = {https://spec.graphql.org/October2021/#sec-Enums},
   addendum = "(accessed: 07.03.2022)",
}

@online{SpecInputObjects,
   title = {GraphQL},
   year={2021},
   url = {https://spec.graphql.org/October2021/#sec-Input-Objects},
   addendum = "(accessed: 07.03.2022)",
}

@online{spec,
   title = {GraphQL},
   year={2022},
   url = {https://spec.graphql.org/},
   addendum = "(accessed: 16.03.2022)",
}

@online{spec-lang,
   title = {GraphQL},
   year={2021},
   url = {https://spec.graphql.org/October2021/#sec-Language},
   addendum = "(accessed: 16.03.2022)",
}

@online{spec-execution,
   title = {GraphQL},
   year={2021},
   url = {https://spec.graphql.org/October2021/#sec-Execution},
   addendum = "(accessed: 16.03.2022)",
}

@online{statejs-2019-graphql,
   title = {The State of JavaScript 2019: GraphQL},
   year={2019},
   url = {https://2019.stateofjs.com/data-layer/graphql/},
   addendum = "(accessed: 16.03.2022)",
}

@book{Richardson2007,
   author = {Leonard Richardson and Sam Ruby and Karen Montgomery and Robert Romano and Jessamyn Read},
   isbn = {978-0-596-52926-0},
   publisher = {O'Reilly Media},
   title = {RESTful Web Services},
   url = {https://archive.org/details/restfulwebservic00rich_0},
   year = {2007},
}

@online{rmm,
   title = {Richardson Maturity Model},
   year={2010},
   url = {https://martinfowler.com/articles/richardsonMaturityModel.html},
   addendum = "(accessed: 30.03.2022)",
}

@online{rest-apis-must-be-hypertext-driven,
   title = {REST APIs must be hypertext-driven » Untangled},
   author = {Roy Thomas Fielding},
   year={2008},
   url = {https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven},
   addendum = "(accessed: 30.03.2022)",
}

@online{apollo-docs,
   title = {Apollo Docs Home - Apollo GraphQL Docs},
   year={2022},
   url = {https://www.apollographql.com/docs/},
   addendum = "(accessed: 22.04.2022)",
}

@incollection{varanasi2015hateoas,
  title={HATEOAS},
  author={Varanasi, Balaji and Belida, Sudha},
  booktitle={Spring REST},
  pages={165--174},
  year={2015},
  publisher={Springer}
}

@book{restful-web-services,
  author={Leonard Richardson and Sam Ruby},
  title = {RESTful Web Services},
  publisher={O’Reilly Media, Inc.},
  address={1005 Gravenstein Highway North, Sebastopol, CA 95472},
  year={2007}
}

@online{owasp-graphql,
   title = {GraphQL - OWASP Cheat Sheet Series},
   year={2021},
   url = {https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#graphql-cheat-sheet},
   addendum = "(accessed: 27.04.2022)",
}

@online{owasp-rest,
   title = {REST Security - OWASP Cheat Sheet Series},
   year={2021},
   url = {https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#graphql-cheat-sheet},
   addendum = "(accessed: 27.04.2022)",
}

@INPROCEEDINGS{vadlamani2021,  
    author={Vadlamani, Sri Lakshmi and Emdon, Benjamin and Arts, Joshua and Baysal, Olga},  
    booktitle={2021 IEEE/ACM 8th International Workshop on Software Engineering Research and Industrial Practice (SER IP)},   
    title={Can GraphQL Replace REST? A Study of Their Efficiency and Viability},   
    year={2021},  
    volume={},  
    number={},  
    pages={10-17},  
    doi={10.1109/SER-IP52554.2021.00009}
}

@article{Wittern2019,
    abstract = {GraphQL is a query language for APIs and a runtime to execute queries. Using
    GraphQL queries, clients define precisely what data they wish to retrieve or
    mutate on a server, leading to fewer round trips and reduced response sizes.
    Although interest in GraphQL is on the rise, with increasing adoption at major
    organizations, little is known about what GraphQL interfaces look like in
    practice. This lack of knowledge makes it hard for providers to understand what
    practices promote idiomatic, easy-to-use APIs, and what pitfalls to avoid. To
    address this gap, we study the design of GraphQL interfaces in practice by
    analyzing their schemas - the descriptions of their exposed data types and the
    possible operations on the underlying data. We base our study on two novel
    corpuses of GraphQL schemas, one of 16 commercial GraphQL schemas and the other
    of 8,399 GraphQL schemas mined from GitHub projects. We make both corpuses
    available to other researchers. Using these corpuses, we characterize the size
    of schemas and their use of GraphQL features and assess the use of both
    prescribed and organic naming conventions. We also report that a majority of
    APIs are susceptible to denial of service through complex queries, posing real
    security risks previously discussed only in theory. We also assess ways in
    which GraphQL APIs attempt to address these concerns.},
    
   author = {Erik Wittern and Alan Cha and James C. Davis and Guillaume Baudart and Louis Mandel},
   doi = {10.48550/arxiv.1907.13012},
   isbn = {9783030337018},
   issn = {16113349},
   journal = {Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)},
   keywords = {GraphQL,Practices,Web AP,Web APIs},
   month = {7},
   pages = {3-19},
   publisher = {Springer},
   title = {An Empirical Study of GraphQL Schemas},
   volume = {11895 LNCS},
   url = {https://arxiv.org/abs/1907.13012v1},
   year = {2019},
}


@article{graphql-analysis,
   abstract = {Facebook's GraphQL is a recently proposed, and increasingly adopted, conceptual framework for providing a new type of data access interface on the Web. The framework includes a new graph query language whose semantics has been specified informally only. The goal of this paper is to understand the properties of this language. To this end, we first provide a formal query semantics. Thereafter, we analyze the language and show that it has a very low complexity for evaluation. More specifically, we show that the combined complexity of the main decision problems is in NL (Nondeterministic Logarithmic Space) and, thus, they can be solved in polynomial time and are highly parallelizable.},
   author = {Olaf Hartig and Jorge Pérez},
   year = {2017},
   title = {An Initial Analysis of Facebook's GraphQL Language},
   journal = {11th Alberto Mendelzon International Workshop on Foundations of Data Management and the Web (AMW)},
   pages = {1–10},
   url = {https://olafhartig.de/files/HartigPerezAMW2017_GraphQL_Preprint.pdf},
}

@article{Hartig2018,
   abstract = {GraphQL is a recently proposed, and increasingly adopted, conceptual framework for providing a new type of data access interface on the Web. The framework includes a new graph query language whose semantics has been specified informally only. This has prevented the formal study of the main properties of the language. We embark on the formalization and study of GraphQL. To this end, we first formalize the semantics of GraphQL queries based on a labeled-graph data model. Thereafter, we analyze the language and show that it admits really efficient evaluation methods. In particular, we prove that the complexity of the GraphQL evaluation problem is NL-complete. Moreover, we show that the enumeration problem can be solved with constant delay. This implies that a server can answer a GraphQL query and send the response byte-by-byte while spending just a constant amount of time between every byte sent. Despite these positive results, we prove that the size of a GraphQL response might be prohibitively large for an internet scenario. We present experiments showing that current practical implementations suffer from this issue. We provide a solution to cope with this problem by showing that the total size of a GraphQL response can be computed in polynomial time. Our results on polynomial-time size computation plus the constant-delay enumeration can help developers to provide more robust GraphQL interfaces on the Web.},
   author = {Olaf Hartig and Jorge Pérez},
   doi = {10.1145/3178876.3186014},
   isbn = {9781450356398},
   journal = {The Web Conference 2018 - Proceedings of the World Wide Web Conference, WWW 2018},
   keywords = {GraphQL,JSON,Query language,Web queries},
   month = {4},
   pages = {1155-1164},
   publisher = {Association for Computing Machinery, Inc},
   title = {Semantics and Complexity of GraphQL},
   url = {https://doi.org/10.1145/3178876.3186014},
   year = {2018},
}

@article{mateusz2020,
   abstract = {The aim of the study was to compare the performance of two data exchange styles commonly used in web applications, i.e. REST and GraphQL. For the purposes of the study two test applications were developed containing the same functionalities, one of which was REST and the other one was GraphQL. They were used for performance tests done with the help of the JMeter tool, during which measurements of the total processing time of requests and the volume of data downloaded and sent were performed. An experiment was developed that tested the basic operations found in most network services: display, add, update, and delete data. The most attention was devoted to the information display operation in the case of which load tests were done. On the basis of performed studies and obtained results, no differences in performance during the operation of adding, editing and deleting data by applications based on REST API and GraphQL were found. During the display operation under heavy load conditions and while downloading small portions of data, the service using GraphQL had a better performance. When downloading large portions of data, the REST-based service exhibited a higher performance.},
   author = {Mateusz Mikuła and Mariusz Dzieńkowski},
   doi = {10.35784/JCSI.2077},
   issn = {2544-0764},
   journal = {Journal of Computer Sciences Institute},
   keywords = {GraphQL,REST,performance testing,web service},
   month = {9},
   pages = {309-316},
   publisher = {Politechnika Lubelska},
   title = {Comparison of REST and GraphQL web technology performance},
   volume = {16},
   url = {https://ph.pollub.pl/index.php/jcsi/article/view/2077},
   year = {2020},
}

@article{Seabra2019,
   abstract = {Given the variety of architectural models that can be used, a frequent questioning among software development practitioners is: which architectural model to use? To respond this question regarding performance issues, three target applications have been studied, each written using two models web services architectures: REST and GraphQL. Through research of performance metrics of response time and the average transfer rate between the requests, it was possible to deduce the particularities of each architectural model in terms of performance metrics. It was observed that migrating to GraphQL. resulted in an increase in performance in two-thirds of the tested applications, with respect to average number of requests per second and transfer rate of data. However, it was noticed that services after migration for GraphQL performed below its REST counterpart for workloads above 3000 requests, ranging from 98 to 2159 Kbytes per second after the migration study. On the other hand, for more trivial workloads, services on both REST and GraphQL architectures presented similar performances, where values between REST and GraphQL services ranged from 6.34 to 7.68 requests per second for workloads of 100 requests.},
   author = {Matheus Seabra and Marcos Felipe Nazário and Gustavo Pinto},
   doi = {10.1145/3357141.3357149},
   isbn = {9781450376372},
   journal = {ACM International Conference Proceeding Series},
   keywords = {GraphQL,Modelo arquitetural,REST,Teste de desempenho},
   month = {9},
   pages = {123-132},
   publisher = {Association for Computing Machinery},
   title = {REST or GraphQL? A performance comparative study},
   year = {2019},
}

@article{helgason2017,
    abstract = {In today's interconnected world, we as users constantly demand more information to be accessible from the web. Not only should the data be accessible but a crucial factor is that load times should be fast. With the internet expanding to more devices of different types such as smartphones, tablets, IoT devices and more, this factor becomes even more important. The most commonly used service today for serving data between clients and a server is REST, which has been the leading service used for this purpose for many years. This research paper focuses on identifying the differences in performance between RESTful services and Facebook's GraphQL. These two technologies are the two most commonly used and talked about solutions when it comes to serving data between clients and servers as of today, with more developers moving towards the newer GraphQL.},
   title = {Performance analysis of Web Services: Comparison between RESTful \& GraphQL web services},
   keywords = {api, programming, networking, graphql, rest, web services},
   author = {Helgason, Arnar Freyr},
   journal = {Digitala Vetenskapliga Arkivet},
   year = {2017},
   url = {https://www.diva-portal.org/smash/record.jsf?pid=diva2\%3A1107850&dswid=-4356},
}

@online{statejs-report,
   title = {The State of JavaScript 2019: GraphQL},
   url = {https://2019.stateofjs.com/data-layer/graphql/},
   year={2019},
   addendum = "(accessed: 15.05.2022)",
}


@online{smartbear-report,
   title = {State of API 2020 Report | SmartBear},
   url = {https://smartbear.com/resources/ebooks/the-state-of-api-2020-report/},
   year={2020},
   addendum = "(accessed: 15.05.2022)",
}

@online{postman-report,
   title = {2021 State of the API Report | API Technologies},
   url = {https://www.postman.com/state-of-api/api-technologies/#api-technologies},
   year={2021},
   addendum = "(accessed: 15.05.2022)",
}

@online{tao-of-node,
   title = {Tao of Node - Design, Architecture & Best Practices | Alex Kondov - Software Engineer},
   author = {Alex Kondov},
   url = {https://alexkondov.com/tao-of-node/#use-hypermedia},
   year={2022},
   addendum = "(accessed: 29.05.2022)",
}

@online{fullstack-rest,
   title = {Fullstack osa3 | Node.js ja Express},
   url = {https://fullstackopen.com/osa3/node_js_ja_express#rest},
   year={2022},
   addendum = "(accessed: 29.05.2022)",
}