1. 3
  1.  

  2. 2

    Instead of a 1:1 mapping between endpoint and entity, I would like to advocate for a 1:1 mapping between endpoint and page.

    The thing is… that’s what REST was always supposed to be. A page is a representation of one resource, which you might model as one entity. If you’re making 10 API requests to render a page, you’re not really doing REST, even if each API request is formally RESTful. You can go one of two ways with this - either drop REST (which is honestly what the front-end-driven web has done), or design your front-ends in a way that is also RESTful. I prefer the latter, but I’m not going to fault anyone for going with the flow and choosing the former.

    IMO this article provides a lot of the understanding people are missing on REST: HATEOAS is for Humans

    1. 2

      Part of the messiness here is that there’s two distinct kinds of “rest API”:

      1. A company supplying their own resources to their frontend.
      2. A SaaS supplying their resources to a third party.

      Different use cases need different practices. Endpoint:page makes sense for (1), endpoint:resource for (2).

      1. 1

        Instead of a 1:1 mapping between endpoint and entity, I would like to advocate for a 1:1 mapping between endpoint and page.

        That’s what the middle end is for. Following this practice in your backend is miserable because you have a backend that’s tightly coupled to the frontend and have to somehow manage keeping things consistent while also maintaining performance.

        If your restful api isn’t doing it for you, try graphql. It allows the frontend to effectively have what endpoint they like for each page.

        1. 2

          This is one major reason why I believe graphQL gained popularity, it was a paradigm shift to move closer to a 1:1 mapping between endpoint and page.