¿Qué tipo de arquitectura permite que los sitios web de SaaS como Salesforce.com eviten que los complementos subóptimos los eliminen?

Salesforce emplea varios métodos que son útiles en diferentes API web para evitar ser degradados por complementos o clientes no autorizados (o ataques maliciosos)

  • Umbralización: Salesforce limita la cantidad de llamadas API que se pueden realizar en un determinado período de tiempo. Por ejemplo, en un período de 24 horas, puede realizar llamadas X API. Si excede ese límite, sus llamadas API fallarán. Estos límites pueden ser por organización o por usuario
  • Conjuntos de resultados limitados: puede solicitar que se devuelva toda la base de datos en una consulta, pero solo obtendrá los primeros 200 resultados en una llamada API. Luego debe subir y solicitar la siguiente página de 200 resultados… .repetir. Cada llamada cuenta contra su límite.
  • API separadas: Salesforce tiene una API masiva y una API SOAP. Están ajustados para las características de rendimiento de diferencia.
  • Optimizar los casos de uso: a menudo, los complementos subóptimos intentan hacer algo útil, pero la función solo se puede impedir de manera deficiente al abusar de la API. En este caso, los gerentes de producto deben identificar el caso de uso y crear una nueva llamada a la API que quizás aborde ese tipo de problema de una manera más efectiva. (vea el anuncio de Twitter recientemente de que ya no incluirán en la lista blanca nuevas aplicaciones que les permitan superar los umbrales de API)
  • Optimizar automáticamente: entiendo que salesforce también tiene un analizador de consultas que puede detectar consultas mal optimizadas y optimizarlas sobre la marcha antes de que llegue a la base de datos.
  • Proteja sus agallas: utilice un controlador / descargador de proxy API como Mashery, APIgee o Sonoa Systems para proteger su API contra DDOS, etc. Estos sistemas también permiten el equilibrio de carga, las transformaciones de API, el almacenamiento en caché de datos, los informes sobre el uso de API y muchos otros cosas que pueden influir en el rendimiento de su API para los usuarios finales. Básicamente se encuentra entre los usuarios finales y su API. Le permiten administrar activamente su API sin cambiar su base de código. Creo que SFDC también usa uno de estos proveedores para administrar su API.
  • Usar ID de aplicación: cada aplicación que use su API debe tener una ID que se use en cada llamada que realice a su API. Esto permite que el proveedor deshabilite selectivamente una sola aplicación en todos sus usuarios que pueda estar causando problemas (y también les permite extraer una “tarifa de certificación” ocasionalmente) para los usuarios. Por ejemplo, Salesforce podría desear deshabilitar el acceso de una aplicación a su plataforma si la aplicación se hubiera visto comprometida.

Lo sentimos, esto fue una gran fuerza de ventas, pero el mejor lugar para encontrar algunos ejemplos es en documentos de desarrollador en API como Twitter, Salesforce, Facebook y muchos otros.

Otra respuesta pesada de Salesforce. La plataforma Force.com hace un trabajo muy completo al evitar que los socios de software de terceros utilicen en exceso los recursos del sistema. Estos se presentan a los desarrolladores como Límites del gobernador (más información en http://www.salesforce.com/us/dev …).

Si bien estos límites son a menudo la ruina de la existencia de cualquier desarrollador de force.com, cumplen un papel crucial para garantizar que nuestras aplicaciones funcionen bien. Mientras tanto, Salesforce ha devuelto a la comunidad de desarrolladores al hacer que estos límites sean más “indulgentes” a medida que aumentan la eficiencia y la capacidad de su plataforma (por ejemplo, la última versión redujo drásticamente las reglas de límites del gobernador).

Finalmente, Salesforce requiere que cualquier proveedor de software de terceros que desee vender sus productos en AppExchange se someta a una revisión de seguridad bastante detallada. Estas revisiones a menudo descubrirán cualquier código que pueda ser una amenaza para la arquitectura.

Un enfoque es el sandboxing JavaScript. Por ejemplo, la plataforma de aplicaciones integradas de PayPal utiliza “Caja”: http://code.google.com/p/google-