Una API describe todos los mensajes válidos que un programa puede aceptar. No dice nada sobre el orden adecuado de estos mensajes, o su interacción con otros programas.
Los protocolos se sientan encima de las API. Un protocolo describe la secuencia válida de mensajes que fluyen entre las API de múltiples partes para realizar alguna tarea de nivel superior.
Entonces, un objeto HTTPRequest podría tener una API como:
- ¿Cómo podemos identificar qué aplicaciones usan TCP y cuáles usan UDP?
- Cómo monitorear el ancho de banda disponible de mi conexión sin afectar una transmisión saliente
- ¿Cuáles son las ventajas de MPLS?
- ¿Existe un marco de prueba de automatización de código abierto para probar protocolos de red?
- ¿Por qué el protocolo BXXP / BEEP no tuvo un impacto mayor?
abierto (método)
addHeader (nombre, valor)
enviar (data, progressHandler)
abortar()
con una API HTTPRequestProgressHandler correspondiente como:
onprogress (percentComplete)
onsuccess ()
onerror ()
onaborted ()
El protocolo para enviar una solicitud con esa API podría ser:
1. Llamada abierta ()
2. Llame a addHeader () según sea necesario
3. Llame a send (), opcionalmente pasando un progressHandler
4. El progressHandler tendrá su método onprogress llamado repetidamente mientras el send () está en progreso
5. Llame a abortar () si es necesario
6. El progressHandler tendrá su método onucess, onerror o onaborted cuando se complete la solicitud.
Tenga en cuenta que el término “mensaje” aquí es conceptual. Las API y los protocolos pueden tener lugar en cualquier medio de comunicación. Los mensajes pueden ser llamadas a funciones locales dentro de un proceso, llamadas IPC dentro de una máquina, bits en un cable, llamadas REST a través de Internet, etc.