title s/connections/pagination

Author: leebyron

site/learn/BestPractice-Authorization.md

@@ -3,7 +3,7 @@ title: Authorization
 layout: ../_core/DocsLayout
 category: Best Practices
 permalink: /learn/authorization/
-next: /learn/connections/
+next: /learn/pagination/
 ---
 
 > Delegate authorization logic to the business logic layer

site/learn/BestPractice-Introduction.md

@@ -60,7 +60,7 @@ Typically fields that could return long lists accept arguments "first" and "afte
 
 Ultimately designing APIs with feature-rich pagination led to a best practice pattern called "Connections". Some client tools for GraphQL, such as [Relay](https://facebook.github.io/relay/), know about the Connections pattern and can automatically provide automatic support for client-side pagination when a GraphQL API employs this pattern.
 
-Read more about this in [Connections](/learn/connections/).
+Read more about this in the article on [Pagination](/learn/pagination/).
 
 
 ### Server-side Batching & Caching

site/learn/BestPractice-Connections.md renamed to site/learn/BestPractice-Pagination.md

@@ -1,11 +1,11 @@
 ---
-title: Connections
+title: Pagination
 layout: ../_core/DocsLayout
 category: Best Practices
-permalink: /learn/connections/
+permalink: /learn/pagination/
 ---
 
-> Different connection models enable different client capabilities
+> Different pagination models enable different client capabilities
 
 A common use case in GraphQL is traversing the relationship between sets of objects. There are a number of different ways that these relationships can be exposed in GraphQL, giving a varying set of capabilities to the client developer.