From 1d2ff1d3f1ee711a710a6ac71e7bd1bc8d5e13bc Mon Sep 17 00:00:00 2001 From: Luis Benitez Date: Tue, 26 Sep 2023 22:38:51 -0300 Subject: [PATCH 1/3] Replace usages of 'compromise' and use assertive language --- docs/tutorial/fastapi/multiple-models.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/tutorial/fastapi/multiple-models.md b/docs/tutorial/fastapi/multiple-models.md index c37fad386b..1786c802dc 100644 --- a/docs/tutorial/fastapi/multiple-models.md +++ b/docs/tutorial/fastapi/multiple-models.md @@ -53,17 +53,17 @@ Here's the weird thing, the `id` currently seems also "optional". 🤔 This is because in our **SQLModel** class we declare the `id` with `Optional[int]`, because it could be `None` in memory until we save it in the database and we finally get the actual ID. -But in the responses, we would always send a model from the database, and it would **always have an ID**. So the `id` in the responses could be declared as required too. +But in the responses, we must always send a model from the database, and it must **always have an ID**. So the `id` in the responses must also be declared as required. -This would mean that our application is making the compromise with the clients that if it sends a hero, it would for sure have an `id` with a value, it would not be `None`. +This means that our application is making the promise to the clients that if it sends a hero, it will for sure have an `id` with a value, it will not be `None`. -### Why Is it Important to Compromise with the Responses +### Why Is it Important to have a contract for Responses The ultimate goal of an API is for some **clients to use it**. The clients could be a frontend application, a command line program, a graphical user interface, a mobile application, another backend application, etc. -And the code those clients write depends on what our API tells them they **need to send**, and what they can **expect to receive**. +And the code those clients write depends on what our API tells them they **need to send**, and what they must **expect to receive**. Making both sides very clear will make it much easier to interact with the API. From 8bce484e84caa44041722ad177bb123fac4b8f07 Mon Sep 17 00:00:00 2001 From: Luis Benitez Date: Tue, 26 Sep 2023 22:41:55 -0300 Subject: [PATCH 2/3] Titleize --- docs/tutorial/fastapi/multiple-models.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorial/fastapi/multiple-models.md b/docs/tutorial/fastapi/multiple-models.md index 1786c802dc..7f9489bc5c 100644 --- a/docs/tutorial/fastapi/multiple-models.md +++ b/docs/tutorial/fastapi/multiple-models.md @@ -57,7 +57,7 @@ But in the responses, we must always send a model from the database, and it must This means that our application is making the promise to the clients that if it sends a hero, it will for sure have an `id` with a value, it will not be `None`. -### Why Is it Important to have a contract for Responses +### Why Is it Important to Have a Contract for Responses The ultimate goal of an API is for some **clients to use it**. From b4e16b0ee86788d306fc5f65baa7f3f8fe20a451 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sebasti=C3=A1n=20Ram=C3=ADrez?= Date: Tue, 24 Oct 2023 00:33:13 +0400 Subject: [PATCH 3/3] =?UTF-8?q?=F0=9F=93=9D=20Tweak=20wording?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/tutorial/fastapi/multiple-models.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/tutorial/fastapi/multiple-models.md b/docs/tutorial/fastapi/multiple-models.md index 7f9489bc5c..6845b9862d 100644 --- a/docs/tutorial/fastapi/multiple-models.md +++ b/docs/tutorial/fastapi/multiple-models.md @@ -53,7 +53,7 @@ Here's the weird thing, the `id` currently seems also "optional". 🤔 This is because in our **SQLModel** class we declare the `id` with `Optional[int]`, because it could be `None` in memory until we save it in the database and we finally get the actual ID. -But in the responses, we must always send a model from the database, and it must **always have an ID**. So the `id` in the responses must also be declared as required. +But in the responses, we always send a model from the database, so it **always has an ID**. So the `id` in the responses can be declared as required. This means that our application is making the promise to the clients that if it sends a hero, it will for sure have an `id` with a value, it will not be `None`. @@ -63,7 +63,7 @@ The ultimate goal of an API is for some **clients to use it**. The clients could be a frontend application, a command line program, a graphical user interface, a mobile application, another backend application, etc. -And the code those clients write depends on what our API tells them they **need to send**, and what they must **expect to receive**. +And the code those clients write depends on what our API tells them they **need to send**, and what they can **expect to receive**. Making both sides very clear will make it much easier to interact with the API.