A protocol defines a set of primitives and their interactions, along with prescriptions where necessary, but is otherwise pretty loose generally. Especially in a Postels law world. APIs tend to be highly prescriptive with a highly specific interface and a lot of black box.

Think of the difference between an IETF RFC on say SMTP vs an email API - the RFC describes how clients and servers for mail routing interact through an almost dialog, while a typical email API has highly structured interfaces. Another wat to cut it is an API can be tested as it has inputs and return values dependent on those, while a protocol you can generally only assert compliance with the specification of the protocol.

People often assert protocols have something to so with RPC of some sort but that’s not true. Many language support protocols, which can be very similar to interfaces, but don’t have anything to do with OOP, etc. In language protocols it’s slightly different than network/IPC protocols but the intent is similar.

I'm not the most knowledgeable, but a protocol talks to another process through a specific format.

I personally think its more powerful than writing a new process to replace and existing.

My favorite example is an X11 windows manager implementing in about 18 lines of python.

Obviously there's dependencies to talk to the X server, but the power of a protocol comes from any program written in any la gage communicate with existing code.

They're both poorly defined, but what I think GP meant is they want something that you use something like a socket instead of FFI to interface with. You need an extra data description layer for a 'protocol' in this context because you can't rely on something like the C data model and calling convention as a given.

A couple ways to look at it:

- Protocols are descriptive, APIs are prescriptive

- Protocols are implemented, APIs implement

A protocol is like the line at Subway where an api is a bar & restaurant.