Merge pull request #14820 from LizCasey1/496030-acro-replace-future-batch1

AAC quality check: Acrolinx clarity fixes - Replace future tense as needed

Author: Stacyrch140

docs/antipatterns/no-caching/index.md

@@ -62,7 +62,7 @@ This antipattern typically occurs because:
 The most popular caching strategy is the *on-demand* or *cache-aside* strategy.
 
 - On read, the application tries to read the data from the cache. If the data isn't in the cache, the application retrieves it from the data source and adds it to the cache.
-- On write, the application writes the change directly to the data source and removes the old value from the cache. It will be retrieved and added to the cache the next time it's required.
+- On write, the application writes the change directly to the data source and removes the old value from the cache. It's retrieved and added to the cache the next time it's required.
 
 This approach is suitable for data that changes frequently. Here is the previous example updated to use the [Cache-Aside][cache-aside-pattern] pattern.
 

docs/best-practices/api-implementation.md

@@ -288,7 +288,7 @@ Cache management is the responsibility of the client application or intermediate
 The *max-age* value in the Cache-Control header is only a guide and not a guarantee that the corresponding data won't change during the specified time. The web API should set the max-age to a suitable value depending on the expected volatility of the data. When this period expires, the client should discard the object from the cache.
 
 > [!NOTE]
-> Most modern web browsers support client-side caching by adding the appropriate cache-control headers to requests and examining the headers of the results, as described. However, some older browsers will not cache the values returned from a URL that includes a query string. This isn't usually an issue for custom client applications which implement their own cache management strategy based on the protocol discussed here.
+> Most modern web browsers support client-side caching by adding the appropriate cache-control headers to requests and examining the headers of the results, as described. But some older browsers don't cache the values returned from a URL that include a query string. This isn't usually an issue for custom client applications that implement their own cache management strategy based on the protocol discussed here.
 >
 > Some older proxies exhibit the same behavior and might not cache requests based on URLs with query strings. This could be an issue for custom client applications that connect to a web server through such a proxy.
 
@@ -578,7 +578,7 @@ A client application that is about to send a large amount of data to a server mi
 
 If you host a service by using Internet Information Services (IIS), the HTTP.sys driver automatically detects and handles Expect: 100-Continue headers before passing requests to your web application. This means that you are unlikely to see these headers in your application code, and you can assume that IIS has already filtered any messages that it deems to be unfit or too large.
 
-If you build client applications by using the .NET Framework, then all POST and PUT messages will first send messages with Expect: 100-Continue headers by default. As with the server-side, the process is handled transparently by the .NET Framework. However, this process results in each POST and PUT request causing two round-trips to the server, even for small requests. If your application isn't sending requests with large amounts of data, you can disable this feature by using the `ServicePointManager` class to create `ServicePoint` objects in the client application. A `ServicePoint` object handles the connections that the client makes to a server based on the scheme and host fragments of URIs that identify resources on the server. You can then set the `Expect100Continue` property of the `ServicePoint` object to false. All subsequent POST and PUT requests made by the client through a URI that matches the scheme and host fragments of the `ServicePoint` object will be sent without Expect: 100-Continue headers. The following code shows how to configure a `ServicePoint` object that configures all requests sent to URIs with a scheme of `http` and a host of `www.contoso.com`.
+If you build client applications by using the .NET Framework, then all POST and PUT messages will first send messages with Expect: 100-Continue headers by default. As with the server-side, the process is handled transparently by the .NET Framework. But this process results in each POST and PUT request causing two round-trips to the server, even for small requests. If your application isn't sending requests with large amounts of data, you can disable this feature by using the `ServicePointManager` class to create `ServicePoint` objects in the client application. A `ServicePoint` object handles the connections that the client makes to a server based on the scheme and host fragments of URIs that identify resources on the server. You can then set the `Expect100Continue` property of the `ServicePoint` object to false. All subsequent POST and PUT requests made by the client through a URI that matches the scheme and host fragments of the `ServicePoint` object are sent without Expect: 100-Continue headers. The following code shows how to configure a `ServicePoint` object that configures all requests sent to URIs with a scheme of `http` and a host of `www.contoso.com`.
 
 ```csharp
 Uri uri = new Uri("https://www.contoso.com/");
@@ -756,7 +756,7 @@ Developers constructing client applications typically require information on how
 
 ### Document the REST operations for a web API
 
-The Azure API Management Service includes a developer portal that describes the REST operations exposed by a web API. When a product has been published it appears on this portal. Developers can use this portal to sign up for access; the administrator can then approve or deny the request. If the developer is approved, they are assigned a subscription key that is used to authenticate calls from the client applications that they develop. This key must be provided with each web API call otherwise it will be rejected.
+The Azure API Management Service includes a developer portal that describes the REST operations exposed by a web API. When a product has been published it appears on this portal. Developers can use this portal to sign up for access; the administrator can then approve or deny the request. If the developer is approved, they're assigned a subscription key that they use to authenticate calls from the client applications that they develop. This key must be provided with each web API call.
 
 This portal also provides: