There are several different ways in which a request may be received and processed within Totara. Having a basic understanding of these is going to help you understand our code structure.
The following list isn't complete, but covers the majority of request/response methods.

Entry pages

By far the most common request/response method, particularly in older versions of Totara.

Totara is a collection of many many scripts, each with one or more purposes relating to the plugin, or component it belongs to.
These scripts each manage their own access control and serve their required functionality.
Internally they serve both views and actions.
When serving views they output HTML.
When performing actions, in most cases they will redirect onwards to a view after an action.

You don't see this approach much any more in modern architectures, with more projects preferring a routed request, and using methodologies such as MVC or MVVM.
We continue to stick to with the multiple entry pages architecture as it works for us, it is deeply embedded within our core platform organised, and it is relied upon heavily by third party plugins and customisations.
Although it is worth noting we do continue to improve and build our internal architecture.
Totara 13 for instance brings a new GraphQL service layer, and ORM API based upon the Eloquent ORM in Laravel.

File resources and assets

Requests for file resources both those provided by the Totara out of the box, and those uploaded by users are served through a mediation layer within the product.

Those provided by core exist within the code base and are web accessible, however are never accessed directly from markup, the mediation layer is always used.
This ensures that plugins and themes can full override and customise the user experience.
It also allows us to ensure that all resources are served with managed headers; importantly we can ensure resources are cached without requiring configuration in the web server, and that they can be purged and controlled within the product.
This includes images, CSS, JavaScript etc. All pass through the mediation layer.

Resources uploaded by users are stored in our WebDav inspired file system, and are served back to end users via a mediation layer also.
All resources uploaded by a user are stored and recorded against the context and area that the images were provided for.
There is no shared pool of resources in Totara, it is all very carefully, and securely curated.
When accessing the resources this allows us to ensure that resources are only ever served to those who have access to the owning context and area.
The files are also served with managed headers, this time to ensure that these resources are not cached, accessed securely, and that they will be handled in the safest way possible on the client; more often then not with all elements of browser guessing disabled and forcing download.

In both cases HTML markup utilising these resources must use URL's provided by the either the output API (for core resources) or the file API for user uploaded resources.

GraphQL services

New to Totara 13 is our GraphQL service layer.
GraphQL architecture is incorporated into the core, component, and plugin architecture and file structure, with each of those being able to define their own GraphQL elements.
Access to the service layer is through purpose dedicated endpoints.
At present there are two:

The AJAX endpoint, used to respond to service requests from browser clients running within the product domain.
The mobile endpoint, used to respond to service requests from our mobile application.

Our expectation is that more end points will exist in the future as third parties develop their own mobile applications and user experiences.
The purpose of having these dedicated endpoints is to facilitate tailoring of the interaction and access control.
In the simplest scenario out of the box the AJAX endpoint will be enabled to serve the browser based user experience, whereas the mobile end point will be disabled until the system has been configured to accept and respond to incoming from our mobile app.

Web services

This is the old service layer, outmoded by GraphQL services.
We will leave this service layer intact and continue to maintain and support it as a great number of services exist already here, both in core, and notably within third party plugins and customisations that we want to continue working.
Web services were defined within core, components, plugins and subplugins.
There were multiple entry points with which you could make a request, the endpoints existed to serve protocols including (SOAP, XMLRPC, etc) unlike the new GraphQL approach of entry points servicing purposes.

Legacy AJAX

These are not created any more, however there are still several areas within Totara that use this approach, and we suspect countless third party plugins that do also.

They originate from earlier days in the product history before the managed service layers mentioned above existed.
In shape and form they look like entry pages discussed above, and in some situations may be mixed in with entry pages.
However unlike entry pages there response is either JSON, or isolated purposeful markup intended to be appended into the DOM on the client.
These scripts take care of their own access control, and functionality.

If you are here because you are looking to handle AJAX requests then please use GraphQL services instead.

Browser not supported