From 371c64d925ea329093321b3ae5e064f83a40b720 Mon Sep 17 00:00:00 2001 From: carson Date: Tue, 21 Sep 2021 15:52:28 -0600 Subject: [PATCH] typo --- www/essays/splitting-your-apis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/www/essays/splitting-your-apis.md b/www/essays/splitting-your-apis.md index 20f90a40..563c2c03 100644 --- a/www/essays/splitting-your-apis.md +++ b/www/essays/splitting-your-apis.md @@ -88,7 +88,7 @@ Once you have split your application API from your generic data API, *you are no a public data API* and are free to reconsider the *entire form* of that application API. We can do whatever we'd like with it, so let's get a bit expansive in our thinking. -Note that core problems with the application API are rapid change and page (or resources) specific tuning. It turns out that we +Note that core problems with the application API are rapid change and page (or resource) specific tuning. It turns out that we have a very good technology for dealing with this: [hypermedia](https://en.wikipedia.org/wiki/Hypermedia)! Hypermedia, by way of HATEOAS, makes API churn [much less of a problem](https://intercoolerjs.org/2016/02/17/api-churn-vs-security.html). When you change the shape of your hypermedia API