It sounds like you need to first understand some fundamentals of the Ethereum EVM, and of Solidity. Start by reading the beige paper (simplified version of the yellow paper), and reading the Solidity docs (https://docs.soliditylang.org/en/latest/).
I'll give you a quick thread to pull on: By "methodID" I assume you mean the function signature. In Solidity, the dispatcher works based on the first 4 bytes of the hash of the function signature (e.g., first 4 bytes of the has of "transfer(address,uint256)". These 4 bytes are known as the "selector." The selector and parameters are encoded according to the external call & calldata ABI (see Solidity docs) and are submitted to the EVM via one of the "call" instructions.
Tools like Etherscan use a json representation of a given contract's "ABI" (IMHO this is a bit of a misnomer but anyway...) generated by the compiler and submitted to Etherscan when the contract is verified. All of that information is also available on IPFS or Swarm if the contract deployer has published it, and the IPFS/Swarm address is also available as a few bytes of metadata appended to the contract code on-chain (again, see Solidity docs).
When you use the "Read the contract" tab on Etherscan, what Etherscan is doing is to use the ABI information in that json metadata to understand how to "call" the contract's functions marked as view or pure, to show you those return values.
https://stackoverflow.com/questions/69186685/argument-calldata-type-encoding-in-solidity
