You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: site/learn/BestPractice-Introduction.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -40,7 +40,7 @@ While there's nothing that prevents a GraphQL service from being versioned just
40
40
41
41
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.
42
42
43
-
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 haslead to a common practice of always avoiding breaking changes and serving a versionless API.
43
+
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 hasled to a common practice of always avoiding breaking changes and serving a versionless API.