dianamontalion/article-as-html.json

## article-as-html.json
{
  "data": {
    "newsletter": {
      "name": "Communication Patterns: APIs",
      "datePublished": "2023-01-12",
      "url": "communication-patterns-apis",
      "text": {
        "html": "<p>In this series, we’ve explored <a rel=\"noopener\" target='_blank' title=\"Communication Patterns: Decoupling\" href=\"https://mentrixgroup.com/newsletter/2022/12/22/communication-patterns-decoupling/\">drawing boundaries</a> around software parts. We’ve discussed <a rel=\"noopener\" target='_blank' title=\"Communication Patterns: Integration\" href=\"https://mentrixgroup.com/newsletter/2023/01/06/communication-patterns-integration/\">integration patterns,</a> forming new relationships between decoupled parts. This week, we explore creating structure for the “sources” of information in a decoupled system. Specifically, how APIs can communicate information in a well-structured way.</p><p>Sources of information have layers; the software part itself, the logic that governs communication, the specific digital locations where communication happens (endpoints) and the information being shared. The layers that interface with consumers and govern communication with the application, are the API (application programming interface).</p><p>Designing these layers will likely be familiar. Even tightly-coupled software (usually) interfaces with other software or resources. Software that serves web pages, for example, is a source of information, with an endpoint (URL) that serves it (to a browser) based on logical rules.</p><p>Sharing information depends, to some extent, on when that information is needed. When a customer buys a product, the software part handling the transaction might want to find out, from another software part, if the customer has a credit that can be applied. When a news article is updated, readers need to see the edited version. In some situations, a consumer checks the source for new information every 24 hours. In others, consumers send bazillions of asynchronous requests.</p><p>We will dive into timing (events) in subsequent weeks. In another edition, we’ll discuss streaming information and events. Here, we’ll specifically look at APIs as the interface to share and retrieve information.</p><p>In its simplest form, an API enables one software part to get information from another software part. <strong>As complexity in a system increases, APIs become integrated into the architecture, essential to the system’s design.</strong> Kubernetes, for example, makes extensive use of APIs to orchestrate interactions across a complex series of services.</p><p>APIs can retrieve information from many types of storage; databases, S3, file systems, as well as operating systems, services running in the cloud, etc. They can be local or remote, using different types of protocols (HTTP, RPC). They can structure responses using XML, JSON or … there isn’t a limiting rule about the structure of responses except that ideally, they are useful and appropriate for the consumer. APIs that return HTML, for example, aren’t helpful to consumers that aren’t displaying web pages.</p><p>The emerging practice of Hypermedia APIs generates responses that are dynamic and discoverable. Instead of getting the static information, consumers get links to endpoints where further, deeper information is available. The consumer’s logic dictates which links to follow. A query language like GraphQL can sit on top of an API so consumers can ask for exactly what they want, across multiple API endpoints, and omit information they don’t need. The more sophisticated our digital systems become, the more avenues of communication design open up.</p><p>Here are some resources to explore APIs. As always, we’d love to hear any recommendations you have!</p>"
      }
    }
  }
}

## article-as-json.json
{
  "data": {
    "newsletter": {
      "name": "Communication Patterns: APIs",
      "datePublished": "2023-01-12",
      "url": "communication-patterns-apis",
      "text": {
        "json": {
          "children": [
            {
              "type": "paragraph",
              "children": [
                {
                  "text": "In this series, we’ve explored "
                },
                {
                  "rel": "noopener",
                  "href": "https://mentrixgroup.com/newsletter/2022/12/22/communication-patterns-decoupling/",
                  "type": "link",
                  "title": "Communication Patterns: Decoupling",
                  "children": [
                    {
                      "text": "drawing boundaries"
                    }
                  ],
                  "openInNewTab": true
                },
                {
                  "text": " around software parts. We’ve discussed "
                },
                {
                  "rel": "noopener",
                  "href": "https://mentrixgroup.com/newsletter/2023/01/06/communication-patterns-integration/",
                  "type": "link",
                  "title": "Communication Patterns: Integration",
                  "children": [
                    {
                      "text": "integration patterns,"
                    }
                  ],
                  "openInNewTab": true
                },
                {
                  "text": " forming new relationships between decoupled parts. This week, we explore creating structure for the “sources” of information in a decoupled system. Specifically, how APIs can communicate information in a well-structured way."
                }
              ]
            },
            {
              "type": "paragraph",
              "children": [
                {
                  "text": "Sources of information have layers; the software part itself, the logic that governs communication, the specific digital locations where communication happens (endpoints) and the information being shared. The layers that interface with consumers and govern communication with the application, are the API (application programming interface)."
                }
              ]
            },
            {
              "type": "paragraph",
              "children": [
                {
                  "text": "Designing these layers will likely be familiar. Even tightly-coupled software (usually) interfaces with other software or resources. Software that serves web pages, for example, is a source of information, with an endpoint (URL) that serves it (to a browser) based on logical rules."
                }
              ]
            },
            {
              "type": "paragraph",
              "children": [
                {
                  "text": "Sharing information depends, to some extent, on when that information is needed. When a customer buys a product, the software part handling the transaction might want to find out, from another software part, if the customer has a credit that can be applied. When a news article is updated, readers need to see the edited version. In some situations, a consumer checks the source for new information every 24 hours. In others, consumers send bazillions of asynchronous requests."
                }
              ]
            },
            {
              "type": "paragraph",
              "children": [
                {
                  "text": "We will dive into timing (events) in subsequent weeks. In another edition, we’ll discuss streaming information and events. Here, we’ll specifically look at APIs as the interface to share and retrieve information."
                }
              ]
            },
            {
              "type": "paragraph",
              "children": [
                {
                  "text": "In its simplest form, an API enables one software part to get information from another software part. "
                },
                {
                  "bold": true,
                  "text": "As complexity in a system increases, APIs become integrated into the architecture, essential to the system’s design."
                },
                {
                  "text": " Kubernetes, for example, makes extensive use of APIs to orchestrate interactions across a complex series of services."
                }
              ]
            },
            {
              "type": "paragraph",
              "children": [
                {
                  "text": "APIs can retrieve information from many types of storage; databases, S3, file systems, as well as operating systems, services running in the cloud, etc. They can be local or remote, using different types of protocols (HTTP, RPC). They can structure responses using XML, JSON or … there isn’t a limiting rule about the structure of responses except that ideally, they are useful and appropriate for the consumer. APIs that return HTML, for example, aren’t helpful to consumers that aren’t displaying web pages."
                }
              ]
            },
            {
              "type": "paragraph",
              "children": [
                {
                  "text": "The emerging practice of Hypermedia APIs generates responses that are dynamic and discoverable. Instead of getting the static information, consumers get links to endpoints where further, deeper information is available. The consumer’s logic dictates which links to follow. A query language like GraphQL can sit on top of an API so consumers can ask for exactly what they want, across multiple API endpoints, and omit information they don’t need. The more sophisticated our digital systems become, the more avenues of communication design open up."
                }
              ]
            },
            {
              "type": "paragraph",
              "children": [
                {
                  "text": "Here are some resources to explore APIs. As always, we’d love to hear any recommendations you have!"
                }
              ]
            }
          ]
        }
      }
    }
  }
}
	{
	"data": {
	"newsletter": {
	"name": "Communication Patterns: APIs",
	"datePublished": "2023-01-12",
	"url": "communication-patterns-apis",
	"text": {
	"html": "<p>In this series, we’ve explored <a rel=\"noopener\" target='_blank' title=\"Communication Patterns: Decoupling\" href=\"https://mentrixgroup.com/newsletter/2022/12/22/communication-patterns-decoupling/\">drawing boundaries</a> around software parts. We’ve discussed <a rel=\"noopener\" target='_blank' title=\"Communication Patterns: Integration\" href=\"https://mentrixgroup.com/newsletter/2023/01/06/communication-patterns-integration/\">integration patterns,</a> forming new relationships between decoupled parts. This week, we explore creating structure for the “sources” of information in a decoupled system. Specifically, how APIs can communicate information in a well-structured way.</p><p>Sources of information have layers; the software part itself, the logic that governs communication, the specific digital locations where communication happens (endpoints) and the information being shared. The layers that interface with consumers and govern communication with the application, are the API (application programming interface).</p><p>Designing these layers will likely be familiar. Even tightly-coupled software (usually) interfaces with other software or resources. Software that serves web pages, for example, is a source of information, with an endpoint (URL) that serves it (to a browser) based on logical rules.</p><p>Sharing information depends, to some extent, on when that information is needed. When a customer buys a product, the software part handling the transaction might want to find out, from another software part, if the customer has a credit that can be applied. When a news article is updated, readers need to see the edited version. In some situations, a consumer checks the source for new information every 24 hours. In others, consumers send bazillions of asynchronous requests.</p><p>We will dive into timing (events) in subsequent weeks. In another edition, we’ll discuss streaming information and events. Here, we’ll specifically look at APIs as the interface to share and retrieve information.</p><p>In its simplest form, an API enables one software part to get information from another software part. <strong>As complexity in a system increases, APIs become integrated into the architecture, essential to the system’s design.</strong> Kubernetes, for example, makes extensive use of APIs to orchestrate interactions across a complex series of services.</p><p>APIs can retrieve information from many types of storage; databases, S3, file systems, as well as operating systems, services running in the cloud, etc. They can be local or remote, using different types of protocols (HTTP, RPC). They can structure responses using XML, JSON or … there isn’t a limiting rule about the structure of responses except that ideally, they are useful and appropriate for the consumer. APIs that return HTML, for example, aren’t helpful to consumers that aren’t displaying web pages.</p><p>The emerging practice of Hypermedia APIs generates responses that are dynamic and discoverable. Instead of getting the static information, consumers get links to endpoints where further, deeper information is available. The consumer’s logic dictates which links to follow. A query language like GraphQL can sit on top of an API so consumers can ask for exactly what they want, across multiple API endpoints, and omit information they don’t need. The more sophisticated our digital systems become, the more avenues of communication design open up.</p><p>Here are some resources to explore APIs. As always, we’d love to hear any recommendations you have!</p>"
	}
	}
	}
	}