HTTP?
It's not perfect, but it seems to be what our industry has settled on as the universal way for pieces of software to talk to each other.
If you are thinking in terms of the payload, JSON seems to be filling that role.
Windows PowerShell communicates with typed objects. COM components and .NET components are a Windows standard way of communicating between software parts. COM has been around for a long time.
Between computers, TCP/IP is a standard way of communicating. But without good documentation of the protocol adding an HTTP layer on top makes it easier to understand. But without good documentation of the protocol RESTful APIs makes it easier to understand. But without good documentation of the protocol WADL...
However I do agree about HTTP. Because I imagine there are more devs that understand HTTP than higher or lower protocols.
Parameters are, for basically all languages, the means by which information is communicated between sub-systems.
The thing is, it is really hard to standardize the communication between sub-systems because sub-routines can vary widely in how they are defined (the possible combination of parameters and types is quite high). In fact, you can end up with thousands of different sub-routines: even in the same program. Each one unique and thus "non-standard".
This is the problem we need to crack. How do we create frameworks that don't lead to thousands of specialized interfaces: each one making the framework that much harder to use.
> api`s for systems that negotiate a communication protocol dynamically
I think the first step is to find a very easy way to describe communication between sub-routines/processes. Once people can hook things up and compose the interaction of software with foreign/unknown systems (all in real time while the software is running) then we can get systems to start doing it dynamically (run on sentence but ya).