API: Link pages to API counterparts

Start by tracing the existing API endpoint go functions, page go/do functions, and DocumentBinder flow described in the issue. Define how an AutoApiPage attribute maps a page to an API endpoint and how POST or PUT do functions are selected. Done means equivalent API data can bind to pages while allowing additional page manipulation and form handling.

A very common web development technique is to design an API first, and then link it to the "front end" via lots of slow ajax calls.

This technique can still be achieved in WebEngine, but because WebEngine is completely server-side, this can be handled automatically.

For example, the following API endpoints can be created:

• api/index - index API will list countries
• api/@country-name e.g. /morocco - list cities within country
• api/@country-name/@city-name e.g. /morocco/rabat - list places within city
• api/@country-name/@city-name/@place-name e.g. /morocco/rabat/national-zoo - show details on place

Once the API endpoints are created, the application's data can be used in other applications, but what if we then wanted to provide a web interface to the data, too?

It would make sense to have the pages follow the same URL structure:

• page/index
• page/@country-name
• page/@country-name/@city-name
• page/@country-name/@city-name/@place-name

These pages will use HTML to structure the content, with data-bind attributes to indicate where the data should be bound.

The PHP should not need to "build" the data up again, because this is already done within the API's PHP logic files. Instead, the go function could be marked with an attribute #[AutoApiPage] or something similar. The presence of this attribute will automatically grab the data that an equivalent API call would respond with, and automatically performs a bind operation to the DocumentBinder. Pages might not have the exact same URL as their API counterparts, so the API endpoint can be passed into the attribute, like #[AutoApiPage("/@country-name/@city-name") for example.

Then, if more manipulation is required to the page, this can be done in the go function as usual.

Submitting a form on a page will trigger a do function. Hooking a do function to the AutoApiPage attribute will call it as a POST request, but if there's multiple do functions on the page - one for updating, one for creating, the HTTP method can be passed in as a parameter like #[AutoApiPage(HttpMethod::PUT)]. Using type juggling, these attribute parameters should be able to be passed in any order.