red-balloon-89377
02/19/2020, 2:29 PMaverage-vr-56795
02/19/2020, 2:55 PMred-balloon-89377
02/19/2020, 2:56 PMaverage-vr-56795
02/19/2020, 3:19 PMred-balloon-89377
02/19/2020, 3:20 PMcompile.zinc
to compile.rsc
, so I guess a combination of 1 and 2average-vr-56795
02/19/2020, 3:25 PMred-balloon-89377
02/19/2020, 5:19 PMgentle-wolf-58752
02/19/2020, 7:18 PMUser-Agent
header - would that help solve what you’re looking to do?aloof-angle-91616
02/19/2020, 9:22 PMVersioning
While there's nothing that prevents a GraphQL service from being versioned just like any other REST API, GraphQL takes a strong opinion on avoiding versioning by providing the tools for the continuous evolution of a GraphQL schema.
Why do most APIs version? When there's limited control over the data that's returned from an API endpoint, any change can be considered a breaking change, and breaking changes require a new version. If adding new features to an API requires a new version, then a tradeoff emerges between releasing often and having many incremental versions versus the understandability and maintainability of the API.
In contrast, GraphQL only returns the data that's explicitly requested, so new capabilities can be added via new types and new fields on those types without creating a breaking change. This has led to a common practice of always avoiding breaking changes and serving a versionless API.