¿Cuál es la mejor manera de hacer una API RPC pública?

Aquí hay algunos principios de diseño para considerar …

Integridad de los datos
Esto es especialmente importante si luego decide agregar un mecanismo de autenticación. Pero, en general, esta debería ser la primera consideración dada a exponer cualquier cosa públicamente en la web. Las API RESTful lo respaldan al asegurar el socket TCP / IP con Secure Sockets Layer (SSL); sin embargo, SSL se puede aplicar a casi cualquier servicio que use TCP como transporte.

Autenticación
Este es un detalle desafiante cuando se trata de una API RPC. Con HTTP, podemos suponer que cada solicitud individual no tiene ningún estado y, por lo tanto, retransmitir los detalles de autenticación con cada solicitud. Obviamente, esto tiene algunos problemas de velocidad. A pesar de que las solicitudes HTTP tienen la capacidad de compartir una sola conexión (y proporcionar algún estado), no se recomienda confiar en esto.

En cambio, un enfoque que podría funcionar aquí es establecer una abstracción en la capa de transporte que proporcione algunos detalles de autenticación para la implementación de sus RPC. Para un transporte HTTP, esto podría implicar pasar los encabezados de autenticación básicos con cada invocación; mientras que para una implementación directamente a través de un socket, podríamos tener un proceso especial de negociación / apretón de manos al comienzo de nuestra sesión.

En última instancia, trate de evitar que la implementación de RPC conozca demasiados detalles sobre el transporte. Si está solicitando encabezados HTTP, de repente tiene que hacer mucha lógica tonta en su implementación de RPC para admitir otros tipos de transportes.

Estrangulamiento
Esto puede no ser un problema para todos los servicios, pero tener la capacidad de limitar automáticamente las solicitudes por IP o usuario es muy valioso. Esto podría ser muy básico, como registrar el número de llamadas RPC realizadas desde una IP o Usuario dado, a algo más complejo y por método.