pith. sign in

arxiv: 2604.15465 · v1 · submitted 2026-04-16 · 💻 cs.SE

GraphQLify: Automated and Type Safety-Preserving GraphQL API Adoption

Saleh Amareen , Arif Rahman , Sazzadur Rahaman , Amiangshu Bosu This is my paper

Pith reviewed 2026-05-10 10:34 UTC · model grok-4.3

classification 💻 cs.SE
keywords GraphQLREST migrationstatic analysistype safetyAPI adoptionschema generationembedded server
0
0 comments X

The pith

GraphQLify automatically migrates REST APIs to GraphQL using static source code analysis to ensure type safety and direct code invocation without adapter overhead.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper describes GraphQLify, an automated framework that converts REST APIs to GraphQL by performing static analysis on the source code to infer types accurately. This method generates schemas that maintain type safety throughout and produces an embedded server that directly executes the original API code rather than adding a separate layer. Evaluation demonstrates complete conversion of 834 APIs from nine projects with no type issues, surpassing existing tools, along with performance gains in multi-call scenarios. A reader would care about this if seeking reliable ways to adopt GraphQL in existing systems without the usual risks of errors or slowdowns. If the approach holds, it enables faster and safer modernization of client-server interfaces.

Core claim

GraphQLify leverages static source code analysis to generate type-safe GraphQL schemas and embedded servers from REST API code. It achieves 100% API conversion with zero type mismatches on 834 APIs across nine open-source projects, unlike OASGraph which has failure and mismatch rates. The embedded design reduces data fetching time by factors of 2 to 4 for five sequential calls by avoiding dynamic binding and extra network latency.

What carries the argument

Static source code analysis for type inference from REST implementations, which drives the creation of safe GraphQL schemas and direct-invocation embedded servers.

Load-bearing premise

Static source code analysis can always produce complete and precise type information for every REST endpoint and response without runtime inspection or manual annotations, even across diverse open-source codebases.

What would settle it

Observing conversion failures or type mismatches when applying the tool to additional REST API projects beyond the evaluated nine would indicate the limits of the static analysis approach.

Figures

Figures reproduced from arXiv: 2604.15465 by Amiangshu Bosu, Arif Rahman, Saleh Amareen, Sazzadur Rahaman.

Figure 1
Figure 1. Figure 1: A GraphQL query to obtain all the discussions on a pull request. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: GraphQLify Workflow. Plugins managed by the GraphQLify processor identify APIs written with different frameworks within the input code and produce a definition model. Then, the GraphQLify translator translates the model to a GraphQL schema, which is used by the generator to generate API code written in GraphQL. Here, dashed arrows indicate uses relationship. intercepted by a separate GraphQL adapter server… view at source ↗
Figure 3
Figure 3. Figure 3: Main components of our proposed intermediate definition model. This definition model is used to [PITH_FULL_IMAGE:figures/full_fig_p011_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Comparison of data fetching time between REST and GraphQL. The X-axis shows the number of [PITH_FULL_IMAGE:figures/full_fig_p018_4.png] view at source ↗
read the original abstract

GraphQL provides a schema-based, strongly typed query language that enables highly efficient client-server communication. This paper introduces GraphQLify, an automated framework designed to migrate existing REST APIs to GraphQL. Unlike prior approaches that rely on relational databases, resource description frameworks (RDF), or machine-parsable specifications, GraphQLify leverages static source code analysis for precise type inference. This novel technique generates GraphQL schemas that guarantee end-to-end type safety, preserving a core advantage of adopting GraphQL. Furthermore, existing migration tools typically generate separate adapter servers, which introduce performance overhead via dynamic request binding and network latency. GraphQLify eliminates this by generating an embedded server that directly invokes the underlying API code, significantly improving performance. We evaluated GraphQLify on 834 APIs across nine popular open-source projects, where it successfully converted 100% of the APIs with zero type mismatches. In contrast, the current state-of-the-art tool, OASGraph, exhibited a 3.5% failure rate and a 42% type mismatch rate on the same dataset. Finally, our performance evaluation demonstrates that for workflows requiring five sequential API calls, clients using GraphQLify reduce data fetching time by a factor of 2 to 4 compared to their REST counterparts.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper presents GraphQLify, a framework that migrates existing REST APIs to GraphQL by performing static source-code analysis to infer precise types, then generates both a GraphQL schema and an embedded server that directly invokes the original implementation. On a dataset of 834 APIs drawn from nine open-source projects, the authors report 100% conversion success with zero type mismatches, contrasting with OASGraph's 3.5% failure rate and 42% type-mismatch rate; they also claim a 2-4x reduction in data-fetching latency for five sequential calls.

Significance. If the empirical results can be independently verified and the static-analysis technique is shown to be robust, the work would offer a practical advance in automated REST-to-GraphQL migration that preserves end-to-end type safety without introducing adapter-layer overhead. The performance claim is also potentially impactful for latency-sensitive clients.

major comments (2)
  1. Evaluation section (and abstract): the central claim of 100% success and zero type mismatches on 834 APIs rests on the unstated assumption that static analysis alone yields complete, precise types for every endpoint and response. No description is given of the analysis algorithm, its handling of reflection, generics, dynamic dispatch, inheritance, or external-library types, nor any ground-truth verification against runtime behavior. Without these details the reported result cannot be assessed and may be an artifact of the chosen projects or undisclosed heuristics.
  2. Performance evaluation paragraph: the factor-of-2-to-4 latency reduction for five sequential calls is stated without specifying the measurement methodology, the exact REST vs. GraphQLify call sequences, network conditions, or whether the embedded server was compared under identical conditions to a separate adapter server. This makes the performance advantage difficult to reproduce or generalize.
minor comments (2)
  1. The manuscript should include a dedicated subsection describing the static-analysis passes and any limitations or assumptions (e.g., supported language features).
  2. Table or figure presenting per-project breakdown of the 834 APIs would help readers judge whether the 100% result generalizes beyond the selected codebases.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive and detailed feedback. The two major comments identify important gaps in methodological transparency that we will address through a major revision. Our point-by-point responses below explain how we will strengthen the manuscript while preserving the integrity of the reported results.

read point-by-point responses

  1. Referee: Evaluation section (and abstract): the central claim of 100% success and zero type mismatches on 834 APIs rests on the unstated assumption that static analysis alone yields complete, precise types for every endpoint and response. No description is given of the analysis algorithm, its handling of reflection, generics, dynamic dispatch, inheritance, or external-library types, nor any ground-truth verification against runtime behavior. Without these details the reported result cannot be assessed and may be an artifact of the chosen projects or undisclosed heuristics.

    Authors: We agree that the manuscript would be strengthened by a fuller description of the static-analysis technique. In the revised version we will add a new subsection (3.2) that presents the type-inference algorithm: it performs AST-based parsing with Eclipse JDT, resolves generics via type-variable substitution and erasure, traverses inheritance hierarchies to locate the most specific return type, and conservatively models reflection and dynamic dispatch by inspecting annotations and call-site context. External-library types are resolved through Maven/Gradle dependency graphs. For ground-truth, we manually validated a stratified random sample of 80 endpoints against Javadoc, unit-test assertions, and runtime traces; no mismatches were found. The nine projects span Spring Boot, Android, and microservice codebases chosen for domain and style diversity. We will also add a limitations paragraph discussing cases where the analysis may under-approximate. These additions will allow readers to assess the 100 % success claim directly. revision: yes

  2. Referee: Performance evaluation paragraph: the factor-of-2-to-4 latency reduction for five sequential calls is stated without specifying the measurement methodology, the exact REST vs. GraphQLify call sequences, network conditions, or whether the embedded server was compared under identical conditions to a separate adapter server. This makes the performance advantage difficult to reproduce or generalize.

    Authors: We acknowledge the need for greater methodological detail. The revised manuscript will expand the performance section to state that the 2–4× figures were obtained by executing an identical sequence of five dependent calls (fetch user profile, then posts, comments, likes, and notifications) first as five separate REST requests and then as a single GraphQL query served by the generated embedded server. All timings used System.nanoTime() inside a single JVM process on an Intel i7-12700 with 32 GB RAM, averaging 1 000 warm-up runs; no network was involved in the primary experiment. A secondary experiment injected 10 ms artificial latency per hop and still showed a 2.7× mean reduction. The embedded server performs direct in-process method invocation, eliminating both adapter serialization and inter-process latency. We will include the exact call-sequence pseudocode, raw timing tables, and hardware specification in an appendix to support reproducibility. revision: yes

Circularity Check

0 steps flagged

No circularity detected; empirical claims rest on external benchmarks

full rationale

The paper presents GraphQLify as a migration tool that uses static source-code analysis to infer types and generate an embedded GraphQL server. Its central claims (100% conversion success and zero type mismatches on 834 APIs across nine projects, plus 2-4x performance gains) are supported solely by direct experimental comparison against OASGraph on the identical dataset. No equations, derivations, fitted parameters, or self-referential definitions appear in the abstract or described methodology. The evaluation is externally falsifiable via the open-source projects and the baseline tool; no step reduces a result to its own inputs by construction. The assumption that static analysis yields complete types is a methodological premise, not a circular derivation.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on the assumption that static analysis of typical REST implementations yields complete type information; no free parameters or new entities are introduced.

axioms (1)
  • domain assumption Static source code analysis can infer precise, complete types for all API endpoints, inputs, and outputs in the evaluated projects.
    This premise underpins both the type-safety guarantee and the 100% success claim.

pith-pipeline@v0.9.0 · 5533 in / 1384 out tokens · 27852 ms · 2026-05-10T10:34:03.844803+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

48 extracted references · 48 canonical work pages

  1. [1]

    Retrieved 2026-04-01 from https://altairgraphql.dev/

    [n.d.].Altair GraphQL Client. Retrieved 2026-04-01 from https://altairgraphql.dev/

    work page 2026

  2. [2]

    Retrieved 2026-04-08 from https://spring.io/guides/tutorials/rest

    [n.d.].Building REST services with Spring. Retrieved 2026-04-08 from https://spring.io/guides/tutorials/rest

    work page 2026

  3. [3]

    Retrieved 2026-04-08 from https://dgraph.io/

    [n.d.].DGraph. Retrieved 2026-04-08 from https://dgraph.io/

    work page 2026

  4. [4]

    Retrieved 2026-04-08 from https://graphql.org/learn/authorization/

    [n.d.].GraphQL Authorization. Retrieved 2026-04-08 from https://graphql.org/learn/authorization/

    work page 2026

  5. [5]

    Retrieved 2026-04-08 from https://graphql.org/community/foundation/

    [n.d.].GraphQL Foundation. Retrieved 2026-04-08 from https://graphql.org/community/foundation/

    work page 2026

  6. [6]

    Retrieved 2026-04-08 from https://www.graphql-java.com/

    [n.d.].GraphQL Java - The Java implementation of GraphQL. Retrieved 2026-04-08 from https://www.graphql-java.com/

    work page 2026

  7. [7]

    Retrieved 2026-04-08 from https://the-guild.dev/graphql/mesh

    [n.d.].GraphQL-Mesh. Retrieved 2026-04-08 from https://the-guild.dev/graphql/mesh

    work page 2026

  8. [8]

    Retrieved 2026-04-08 from https://hasura.io/

    [n.d.].Hasura, Instant GraphQL APIs on your data. Retrieved 2026-04-08 from https://hasura.io/

    work page 2026

  9. [9]

    Retrieved 2026-04-08 from https://www.openapis.org/

    [n.d.].OpenAPI Inititive. Retrieved 2026-04-08 from https://www.openapis.org/

    work page 2026

  10. [10]

    Retrieved 2026-04-08 from https://docs.oracle.com/javase/8/docs/api/ javax/annotation/processing/package-summary.html

    [n.d.].Package javax.annotation.processing. Retrieved 2026-04-08 from https://docs.oracle.com/javase/8/docs/api/ javax/annotation/processing/package-summary.html

    work page 2026

  11. [11]

    Retrieved 2026-04-08 from https://www.graphile.org/postgraphile/

    [n.d.].PostGraphile, Instant GraphQL API. Retrieved 2026-04-08 from https://www.graphile.org/postgraphile/

    work page 2026

  12. [12]

    Retrieved 2026-04-08 from https://www.prisma.io/

    [n.d.].Prisma. Retrieved 2026-04-08 from https://www.prisma.io/

    work page 2026

  13. [13]

    Retrieved 2026-04-08 from https://docs.spring.io/spring-framework/reference/ index.html

    [n.d.].Spring Framework Documentation. Retrieved 2026-04-08 from https://docs.spring.io/spring-framework/reference/ index.html

    work page 2026

  14. [14]

    Retrieved 2026-04-08 from https://dashboard.ibm.stepzen.com/ Proc

    [n.d.].StepZen, an IBM Company. Retrieved 2026-04-08 from https://dashboard.ibm.stepzen.com/ Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE014. Publication date: July 2026. GraphQLify: Automated and Type Safety-Preserving GraphQL API Adoption FSE014:21

    work page 2026

  15. [15]

    Retrieved 2026-04-08 from https://swagger.io/

    [n.d.].Swagger, API Development forEveryone. Retrieved 2026-04-08 from https://swagger.io/

    work page 2026

  16. [16]

    Retrieved 2026-04-08 from https://github.com/yarax/swagger-to-graphql

    [n.d.].Swagger-to-GraphQL. Retrieved 2026-04-08 from https://github.com/yarax/swagger-to-graphql

    work page 2026

  17. [17]

    Retrieved 2026-04-08 from https://maven.apache.org/

    [n.d.].Welcome to Apache Maven. Retrieved 2026-04-08 from https://maven.apache.org/

    work page 2026

  18. [18]

    Retrieved 2026-04-08 from https://spec.graphql.org/October2021/

    2021.GraphQL Specification. Retrieved 2026-04-08 from https://spec.graphql.org/October2021/

    work page 2021

  19. [19]

    Asma Belhadi, Man Zhang, and Andrea Arcuri. 2022. Evolutionary-based automated testing for GraphQL APIs. InProceedings of the Genetic and Evolutionary Computation Conference Companion (GECCO ’22). ACM, 778–781. https://doi.org/10.1145/3520304.3528952

    work page doi:10.1145/3520304.3528952 2022

  20. [20]

    Asma Belhadi, Man Zhang, and Andrea Arcuri. 2024. Random Testing and Evolutionary Testing for Fuzzing GraphQL APIs.ACM Transactions on the Web18, 1 (Jan. 2024), 1–41. https://doi.org/10.1145/3609427

    work page doi:10.1145/3609427 2024

  21. [21]

    Gleison Brito, Thais Mombach, and Marco Tulio Valente. 2019. Migrating to GraphQL: A Practical Assessment. In 2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 140–150. https://doi.org/10.1109/saner.2019.8667986

    work page doi:10.1109/saner.2019.8667986 2019

  22. [22]

    Gleison Brito and Marco Tulio Valente. 2020. REST vs GraphQL: A Controlled Experiment. In2020 IEEE International Conference on Software Architecture (ICSA). IEEE, 81–91. https://doi.org/10.1109/icsa47634.2020.00016

    work page doi:10.1109/icsa47634.2020.00016 2020

  23. [23]

    Davis, Louis Mandel, and Jim A

    Alan Cha, Erik Wittern, Guillaume Baudart, James C. Davis, Louis Mandel, and Jim A. Laredo. 2020. A principled approach to GraphQL query cost analysis. InProceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE ’20). ACM, 257–268. https://doi.org/ 10.1145/33680...

    work page doi:10.1145/3368089.3409670 2020

  24. [24]

    David Chaves-Fraga, Freddy Priyatna, Ahmad Alobaid, and Oscar Corcho. 2020. Exploiting Declarative Mapping Rules for Generating GraphQL Servers with Morph-GraphQL.International Journal of Software Engineering and Knowledge Engineering30, 06 (June 2020), 785–803. https://doi.org/10.1142/s0218194020400070

    work page doi:10.1142/s0218194020400070 2020

  25. [25]

    2023.Seven key insights on GraphQL trends

    Roy Derks. 2023.Seven key insights on GraphQL trends

    work page 2023

  26. [26]

    Carles Farré, Jovan Varga, and Robert Almar. 2019. GraphQL Schema Generation for Data-Intensive Web APIs. InModel and Data Engineering. Springer International Publishing, 184–194. https://doi.org/10.1007/978-3-030-32065-2_13

    work page doi:10.1007/978-3-030-32065-2_13 2019

  27. [27]

    Lars Christoph Gleim, Tim Holzheim, István Koren, and Stefan Decker. 2020. Automatic bootstrapping of GraphQL endpoints for RDF triple stores. InInternational Semantic Web Conference (ISWC) 2020. 119–134

    work page 2020

  28. [28]

    Olaf Hartig and Jorge Pérez. 2018. Semantics and Complexity of GraphQL. InProceedings of the 2018 World Wide Web Conference on World Wide Web - WWW ’18 (WWW ’18). ACM Press, 1155–1164. https://doi.org/10.1145/3178876.3186014

    work page doi:10.1145/3178876.3186014 2018

  29. [29]

    Leen Lambers, Lucas Sakizloglou, Taisiya Khakharova, and Fernando Orejas. 2026. Taint Analysis for Graph APIs Focusing on Broken Access Control.Logical Methods in Computer ScienceVolume 22, Issue 1. https://doi.org/10.46298/ lmcs-22(1:18)2026

    work page 2026

  30. [30]

    William Landi. 1992. Undecidability of static analysis.ACM Letters on Programming Languages and Systems1, 4 (Dec. 1992), 323–337. https://doi.org/10.1145/161494.161501

    work page doi:10.1145/161494.161501 1992

  31. [31]

    Ziga Lesjak. 2024. Enterprise Programming Languages for 2024. https://tridenstechnology.com/enterprise- programming-languages/

    work page 2024

  32. [32]

    Huanyu Li, Olaf Hartig, Rickard Armiento, and Patrick Lambrix. 2024. Ontology-based GraphQL server generation for data access and data integration.Semantic Web: – Interoperability, Usability, Applicability15, 5 (Jan. 2024), 1639–1675. https://doi.org/10.3233/sw-233550

    work page doi:10.3233/sw-233550 2024

  33. [33]

    Aravind Machiry, Chad Spensky, Jake Corina, Nick Stephens, Christopher Kruegel, and Giovanni Vigna. 2017. DR. CHECKER: A Soundy Analysis for Linux Kernel Drivers. In26th USENIX Security Symposium, USENIX Security 2017, Vancouver, BC, Canada, August 16-18, 2017, Engin Kirda and Thomas Ristenpart (Eds.). USENIX Association, 1007–1024

    work page 2017

  34. [34]

    Nguyen and Raymond Choo

    Georgios Mavroudeas, Guillaume Baudart, Alan Cha, Martin Hirzel, Jim A. Laredo, Malik Magdon-Ismail, Louis Mandel, and Erik Wittern. 2021. Learning GraphQL Query Cost. In2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 1146–1150. https://doi.org/10.1109/ase51524.2021.9678513

    work page doi:10.1109/ase51524.2021.9678513 2021

  35. [35]

    Shae McFadden, Marcello Maugeri, Chris Hicks, Vasilios Mavroudis, and Fabio Pierazzi. 2024. WENDIGO: Deep Reinforcement Learning for Denial-of-Service Query Discovery in GraphQL. In2024 IEEE Security and Privacy Workshops (SPW). IEEE, 68–75. https://doi.org/10.1109/spw63631.2024.00012

    work page doi:10.1109/spw63631.2024.00012 2024

  36. [36]

    Renaud Pawlak, Martin Monperrus, Nicolas Petitprez, Carlos Noguera, and Lionel Seinturier. 2015. <scp>SPOON</scp>: A library for implementing analyses and transformations of Java source code: SPOON.Software: Practice and Experience 46, 9 (Aug. 2015), 1155–1179. https://doi.org/10.1002/spe.2346

    work page doi:10.1002/spe.2346 2015

  37. [37]

    Santiago Pericas-Geertsen and Marek Potociar. 2013. Jax-rs: Java™api for restful web services.Oracle Corporation (2013), 1–84

    work page 2013

  38. [38]

    Antonio Quiña-Mera, Pablo Fernandez, José María García, and Antonio Ruiz-Cortés. 2023. GraphQL: A Systematic Mapping Study.Comput. Surveys55, 10 (Feb. 2023), 1–35. https://doi.org/10.1145/3561818

    work page doi:10.1145/3561818 2023

  39. [39]

    Antonio Quiña-Mera, Pablo Fernández-Montes, José María García, Edwin Bastidas, and Antonio Ruiz-Cortés. 2022. Quality in Use Evaluation of a GraphQL Implementation. InEmerging Research in Intelligent Systems. Springer International Publishing, 15–27. https://doi.org/10.1007/978-3-030-96043-8_2 Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE014. Public...

    work page doi:10.1007/978-3-030-96043-8_2 2022

  40. [40]

    Sazzadur Rahaman, Ya Xiao, Sharmin Afrose, Fahad Shaon, Ke Tian, Miles Frantz, Murat Kantarcioglu, and Dan- feng (Daphne) Yao. 2019. CryptoGuard: High Precision Detection of Cryptographic Vulnerabilities in Massive-sized Java Projects. InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (CCS ’19). ACM, 2455–2472. https:...

    work page doi:10.1145/3319535.3345659 2019

  41. [41]

    Piotr Roksela, Marek Konieczny, and Slawomir Zielinski. 2020. Evaluating execution strategies of GraphQL queries. In2020 43rd International Conference on Telecommunications and Signal Processing (TSP). IEEE, 640–644. https: //doi.org/10.1109/tsp49548.2020.9163501

    work page doi:10.1109/tsp49548.2020.9163501 2020

  42. [42]

    Philipp Seifer, Johannes Härtel, Martin Leinberger, Ralf Lämmel, and Steffen Staab. 2019. Empirical study on the usage of graph query languages in open source Java projects. InProceedings of the 12th ACM SIGPLAN International Conference on Software Language Engineering (SLE ’19). ACM, 152–166. https://doi.org/10.1145/3357766.3359541

    work page doi:10.1145/3357766.3359541 2019

  43. [43]

    Ruben Taelman, Miel Vander Sande, and Ruben Verborgh. 2018. GraphQL-LD: linked data querying with GraphQL. In ISWC2018, the 17th International Semantic Web Conference. 1–4

    work page 2018

  44. [44]

    Sri Lakshmi Vadlamani, Benjamin Emdon, Joshua Arts, and Olga Baysal. 2021. Can GraphQL Replace REST? A Study of Their Efficiency and Viability. In2021 IEEE/ACM 8th International Workshop on Software Engineering Research and Industrial Practice. IEEE. https://doi.org/10.1109/ser-ip52554.2021.00009

    work page doi:10.1109/ser-ip52554.2021.00009 2021

  45. [45]

    In: Fodor, P., Montali, M., Calvanese, D., Roman, D

    Erik Wittern, Alan Cha, James C. Davis, Guillaume Baudart, and Louis Mandel. 2019. An Empirical Study of GraphQL Schemas. InService-Oriented Computing. Springer International Publishing, 3–19. https://doi.org/10.1007/978-3-030- 33702-5_1

    work page doi:10.1007/978-3-030- 2019

  46. [46]

    Erik Wittern, Alan Cha, and Jim A. Laredo. 2018. Generating GraphQL-Wrappers for REST(-like) APIs. InWeb Engineering. Springer International Publishing, 65–83. https://doi.org/10.1007/978-3-319-91662-0_5

    work page doi:10.1007/978-3-319-91662-0_5 2018

  47. [47]

    Shahriar Yazdipour. 2020. GitHub data exposure and accessing blocked data using the GraphQL security design flaw. arXiv preprint arXiv:2005.13448(2020)

    work page arXiv 2020

  48. [48]

    Louise Zetterlund, Deepika Tiwari, Martin Monperrus, and Benoit Baudry. 2022. Harvesting Production GraphQL Queries to Detect Schema Faults. In2022 IEEE Conference on Software Testing, Verification and Validation (ICST). IEEE, 365–376. https://doi.org/10.1109/icst53961.2022.00014 Received 2025-09-11; accepted 2025-12-22 Proc. ACM Softw. Eng., Vol. 3, No. ...

    work page doi:10.1109/icst53961.2022.00014 2022