CODE RUB: Communication Protocols 3.1 Grammer Check

3. Exposers/3.1 Communication Protocols/3.1 Communication Protocols.md

@@ -1,35 +1,35 @@
 # 3.1 Communication Protocols
 
 ## 3.1.0 Introduction
-In the exposure realm, one of the most common methodologies to build a communication structure between several systems is to use a communication protocol. These protocols have evolved over the years from SOAP to REST to many other communication protocols and principles that manifested their own technologies to expose APIs to distributed systems.
+In the exposure realm, one of the most common methodologies for building a communication structure between several systems is using a communication protocol. These protocols have evolved over the years from SOAP to REST to many other communication protocols and principles that manifested their technologies to expose APIs to distributed systems.
 
 In the .NET world, technology has evolved with the evolution of architecture from SOA with WCF to Microservices with REST. The evolution continues, but the principles change less often. In these upcoming chapters, we will discuss the most common communication protocols with a standardized way to implement them for enterprise-level applications.
 
 ### 3.1.0.0 Principles & Rules
 Communication protocols are required to accomplish two things when integrating with core business logic. Results communication and Error reporting. Let's talk about those briefly:
 
 #### 3.1.0.0.0 Results Communication
-Any communication protocol must satisfy the principle of returning a core business logic result. This result can be serialized into some unified language like `JSON` or be communicated as is. In the case of API libraries, there is usually no need to serialize and deserialize data. But that comes with the limitation that only technologies that integrate with these libraries can benefit from it.
+Any communication protocol must satisfy the principle of returning a core business logic result. This result can be serialized into a unified language like `JSON` or communicated as is. In the case of API libraries, there is usually no need to serialize and deserialize data. However, that comes with the limitation that only technologies that integrate with these libraries can benefit from it.
 
 Communicating results may also be encapsulated with a status of some kind. In the case of RESTful API communications, a `200` code can accompany the returned serialized `JSON` result. These codes allow the consumers to understand the next course of action. Some `2xx` results may require a delayed action if the response is just `Accepted` but not necessarily `Created`.
 
 #### 3.1.0.0.1 Error Reports
-The core business logic should provide a detailed report of all the validation errors in a particular request. The communication protocols' responsibility is to represent these error reports in their original form or serialize the report in a language easily deserialized and convertible back into the Exception original form on the client side.
+The core business logic should provide a detailed report of all the validation errors in a particular request. The communication protocols' responsibility is to represent these error reports in their original form or serialize them in a language easily deserialized and convertible back into the Exception original form on the client side.
 
-Serialized error reports shall also have their own codes, so the client knows the next course of action. We recommend following a standardized way of communicating errors with documentation, preferably to help guide consumers to develop the best clients for these APIs.
+Serialized error reports shall also have their own codes so the client knows the next course of action. We recommend following a standardized way of communicating errors with documentation, preferably to help guide consumers in developing the best clients for these APIs.
 
 ### 3.1.0.1 Common Types
 Let's explore some of the most common types of communication protocols in this section.
 
 #### 3.1.0.1.0 REST
-REST is a Representational state transfer protocol with certain constraints that explicitly define the form of communication, error reporting, and its very stateless nature. At the time of authoring this Standard, RESTful APIs were the most common form of communication between distributed systems. RESTful APIs are technology agnostic. Any technology or a programming language can implement them, and they allow these technologies to communicate with each other statelessly without any hard dependency on the server or the client's choice of technology.
+REST is a Representational state transfer protocol with certain constraints that explicitly define the form of communication, error reporting, and its very stateless nature. When this Standard was authored, RESTful APIs were the most common form of communication between distributed systems. RESTful APIs are technology-agnostic. Any technology or a programming language can implement them, and they allow these technologies to communicate with each other statelessly without any hard dependency on the server or the client's choice of technology.
 
 #### 3.1.0.1.1 Libraries
 The other most common communication protocol is APIs implemented within libraries. For instance, NuGet packages are published and distributed libraries that allow developers to leverage a localized core business logic or communicate with an external resource to achieve a specific goal.
 
 #### 3.1.0.1.2 Other Types
-There are several other types of communication protocols. Some are older, and others are about to present themselves in the software industry. These types are like SOAP with manifestations like WCF, gRPC, GraphQL, and several other protocols.
+There are several other types of communication protocols. Some are older, and others are about to emerge in the software industry. These types are like SOAP with manifestations like WCF, gRPC, GraphQL, and several others.
 
-We will mainly focus on RESTful APIs as a more common communication protocol with a brief touch on Libraries. And as we evolve and learn further, so will our Standard, which will include more and more different communication protocols and develop in terms of patterns, as well.
+We will mainly focus on RESTful APIs as a more common communication protocol, with a brief touch on Libraries. As we evolve and learn further, so will our Standard, which will include more and more different communication protocols and develop in terms of patterns.
 
-Let's get started with RESTful APIs as a communication protocol and dive deeper into the different aspects of that exposer component.
+Let's start with RESTful APIs as a communication protocol and then explore the different aspects of the exposer component.