itsscb/htmx
1
0
Fork 0
mirror of https://github.com/bigskysoftware/htmx.git synced 2025-10-02 15:25:26 +00:00
Code Issues Packages Projects Releases Wiki Activity

formatting

Browse Source
This commit is contained in:
carson 2021-09-21 15:51:44 -06:00
parent 40606158fa
commit f0874f0dad
1 changed files with 7 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
www/essays/splitting-your-apis.md
View File

@ -57,13 +57,16 @@ Max's recommendation is to split the API into two "halves": a generic API and an
I agree entirely with Max on the problem here. I agree entirely with Max on the problem here.
I would particularly emphasise the fact that the generic API needs to I would particularly emphasise the fact that the generic API needs to be stable, whereas the application API must change
be stable, whereas the application API must change rapidly to address application needs. Jean-Jacques Dubray, in rapidly to address application needs.
[this article](https://www.infoq.com/articles/no-more-mvc-frameworks/) relates the following sad state of affairs for
Jean-Jacques Dubray, in [this article](https://www.infoq.com/articles/no-more-mvc-frameworks/) relates the following sad state of affairs for
API designers: API designers:
> The worst part of my job these days is designing APIs for front-end developers. The conversation goes inevitably as: > The worst part of my job these days is designing APIs for front-end developers. The conversation goes inevitably as:
>
> Dev – So, this screen has data element x,y,z… could you please create an API with the response format {x: , y:, z: } > Dev – So, this screen has data element x,y,z… could you please create an API with the response format {x: , y:, z: }
>
> Me – Ok > Me – Ok
This is a perfect encapsulation of the tension that Max has noticed, where API engineers want to design general, This is a perfect encapsulation of the tension that Max has noticed, where API engineers want to design general,
@ -82,7 +85,7 @@ that, rather than bailing out to a solution to like GraphQL, you split the APIs
However, there is a **next step** to take: However, there is a **next step** to take:
Once you have split your application API from your generic data API, *you are no longer bound by the constraints of Once you have split your application API from your generic data API, *you are no longer bound by the constraints of
a public data API and are free to reconsider the *entire form* of that application API. We can do whatever we'd like with 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. 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 resources) specific tuning. It turns out that we