diff --git a/README.md b/README.md index 97e56db29..e9f69c661 100644 --- a/README.md +++ b/README.md @@ -338,7 +338,7 @@ both plugins in one projection: strategies, URI interfaces, shared types, etc. * `smithy-http` provides HTTP core modules and interfaces required to build HTTP service clients, including optional HTTP client implementations. - Currently it provides two async HTTP clients that are useable with the + Currently it provides two async HTTP clients that are usable with the `aiohttp` or `awscrt` optional dependency sets respectively. * `smithy-aws-core` provides implementations of `smithy-core` interfaces for AWS, such as SigV4 signers. diff --git a/designs/http-interfaces.md b/designs/http-interfaces.md index 7adcfd408..08526d625 100644 --- a/designs/http-interfaces.md +++ b/designs/http-interfaces.md @@ -172,7 +172,7 @@ class FieldPosition(Enum): class Field(Protocol): """A name-value pair representing a single field in a request or response. - The kind will dictate metadata placement within an the message, for example as + The kind will dictate metadata placement within the message, for example as header or trailer field in a HTTP request as defined in RFC 9110 Section 5. All field names are case insensitive and case-variance must be treated as diff --git a/designs/retries.md b/designs/retries.md index 139660b23..ea1e5f0e8 100644 --- a/designs/retries.md +++ b/designs/retries.md @@ -1,7 +1,7 @@ # Retries Operation requests might fail for a number of reasons that are unrelated to the -input paramters, such as a transient network issue, or excessive load on the +input parameters, such as a transient network issue, or excessive load on the service. This document describes how Smithy clients will automatically retry in those cases, and how the retry system can be modified. diff --git a/designs/serialization.md b/designs/serialization.md index db11bde7b..a3e3011a3 100644 --- a/designs/serialization.md +++ b/designs/serialization.md @@ -14,16 +14,16 @@ based on information from a Smithy model. * Hot-swappable - Implementations should be flexible enough to be swapped at runtime if necessary. If a service supports more than one protocol, it should be trivially easy to swap between them, even at runtime. -* Flexible - Implementations should be useable for purposes other than as a +* Flexible - Implementations should be usable for purposes other than as a component of making a request to a web service. Customers should be able to feed well-formed data from any source into a protocol and have it transform that data with no side-effects. -## Terminology - `Protocol` vs protcol +## Terminology - `Protocol` vs protocol In Smithy, a "protocol" is a method of communicating with a service over a particular transport using a particular format. For example, the -`aws.protocols#RestJson1` protocol is a protocol that communicates over the an +`aws.protocols#RestJson1` protocol is a protocol that communicates over an HTTP transport that makes use of REST bindings and formats structured HTTP payloads in JSON. @@ -46,7 +46,7 @@ class ImplicitImplementation: ``` Since this is *structural* subtyping, it isn't required that implementations -actual inheret from the `Protocol` or otherwise declare that they're +actually inherit from the `Protocol` or otherwise declare that they're implementing it. But they *can* to make it more explicit or to inherit a default implementation. The `Protocol` class itself cannot be instantiated, however. @@ -602,7 +602,7 @@ members dictionary. Recursive members are added at the end, regardless of where they appear in the model.) Doing member dispatch this way is an optimization, which uses relatively simple -integer comparision instead of the comparatively more expensive string +integer comparison instead of the comparatively more expensive string comparison needed to compare based on the member name. Further testing needs to be done in Python to determine whether the performance impact justifies the extra artifact size. In other language, the compiler is also capable of turning