|
Depends on your API, I think. API's are usually more flexible and powerful than the rendered pages that make use of them. At some point, we have to lock down the data. And in a server rendered multi-page website (henceforth just 'MPA'), that point is on each page, while for an SPA it's in the API. In an SPA, we call the API to fetch x, y, & z to render it. In an MPA, we query the database to fetch x, y, & z to render it. Since the query to the database is entirely server side, it does not need to be locked down in the same way that the API does. Mentally, it's a lot easier to look at the /admin/orders page and say "should this user be able to see all this data that I can see is visible?". It's a lot harder to wrap your head around all the myriad ways that someone might call the API, and understand whether you've let anything slip through. With the MPA, those items that shouldn't be there should be pretty obvious, just by looking at the page and seeing what data is visible. For an MPA, the data available to the client is all and only what is rendered on a page. For an SPA, it's all and only what is available through the API. You'll be looking at rendered pages frequently as you develop, but you will rarely (never?) be looking at the full possible output of the API. Some people will lock down which queries can be called against the API in production. This can mitigate some of the issues here, and is probably good practice for websites that aren't intending to make their API available directly. Particularly GraphQL API's. |