Unfortunately Quantum does not have detailed developer documentation that help understand what's going on without having to analyse the code.
I would dare to say that an easy way to look at Quantum API call stacks it to look at the logs. There's already plenty of logging when debug mode is enabled, and that might help you identifying the modules which participate in dispatching API calls. Further, you can add your own logging to get even more details. I remember I used this approach a loooong time ago to understand how the garbage collector worked inside the JVM, and quantum is an awful lot simpler than that!
However, in a nutshell the mechanism works as follows:
- The main binary, quantum-server does a series of calls which create and start a wsgi server:
https://github.com/openstack/quantum/blob/master/quantum/service.py#L104
- The application that the server will run is created using pastedeploy:
https://github.com/openstack/quantum/blob/master/quantum/common/config.py#L123
- api-paste.ini specifies the factory method which creates the app:
https://github.com/openstack/quantum/blob/master/etc/api-paste.ini#L24
- The above method return an instance of the APIRouter class:
https://github.com/openstack/quantum/blob/master/quantum/api/v2/router.py#L68
This class wires instance of the generic Controller class to the various Quantum core API resources using the routes package.
NOTE: the init mechanism for extension is similar, even if the code paths are different
The last step (the mapping performed by the RouteMapper) is what allow a REST call like POST /networks to be dispatched onto a call to the create() method in the instance of the Controller class for the 'networks' resource.
Once the method is dispatched to the controller, several things happen, which can be summarized as follow:
- Request authorization using policy engine
- Input validation
- Dispatch to plugin
- for instance create() on 'networks' resource gets converted into create_network() on the plugin class
- Output view formatting
Note that serialization/deserialization is performed in the WSGI layer. Requests sent to API controller are already deserialized; the API controller return un-serialized data.
Have you looked a the source code, the answer should be there for you.