Hi Joris,
There is no documentation that defines mappings between APIs and PEPs. Hence this new issue we've created:
We'll work on providing documentation for this, but until then, the best source for seeing which PEP an API will trigger is:
That file defines API definitions for all APIs except API plugins.
Below is the API definition for the PUT API. I'll highlight the important information regarding your question.
{
DATA_OBJ_PUT_AN, RODS_API_VERSION, REMOTE_USER_AUTH, REMOTE_USER_AUTH,
"DataObjInp_PI", 1, "PortalOprOut_PI", 0,
boost::any(std::function<int(rsComm_t*,dataObjInp_t*,bytesBuf_t*,portalOprOut_t**)>(RS_DATA_OBJ_PUT)),
"api_data_obj_put", clearDataObjInp,
(funcPtr)CALL_DATAOBJINP_BYTESBUFINP_PORTALOPROUT
},
Each entry will contain a string starting with
api_ (
See the 5th line in the example above)- This string is part of the PEP signature that will be invoked as a result of calling the function, RS_DATA_OBJ_PUT (explained later)
- Upon invoking this API, the server will generate the full PEP name using this string (e.g. <prefix> + "api_data_obj_put" + <class>)
- <prefix> will be "pep_"
- <class> will be expanded to pre, post, except, or finally
Now, RS_DATA_OBJ_PUT is a macro that expands to a function or nothing. If you search the file for that macro, you'll come across the following line:
- #define RS_DATA_OBJ_PUT NULLPTR_FOR_CLIENT_TABLE(rsDataObjPut)
In parentheses, notice the rsDataObjPut symbol. That is the server-side API function that will be run upon invoking rcDataObjPut.
iput calls rcDataObjPut which will cause the server to lookup the API definition for the PUT API. With the API definition in hand, the server knows which server-side function and PEP to invoke.
Hope that helps,
Kory Draughn
Chief Technologist
iRODS Consortium