En este documento, se presentan técnicas que puedes usar para mejorar el rendimiento de tu aplicación. En algunos casos, se usan ejemplos de otras API o de API genéricas para ilustrar las ideas presentadas. Sin embargo, los mismos conceptos se aplican a la API de Android Over The Air.
Compresión con gzip
Una forma fácil y conveniente de reducir el ancho de banda necesario para cada solicitud es habilitar la compresión gzip. Aunque esto requiere un tiempo de CPU adicional para descomprimir los resultados, la compensación con los costos de la red suele hacer que valga la pena.
Si quieres recibir una respuesta codificada en gzip, debes establecer un encabezado de Accept-Encoding y modificar tu usuario-agente para que contenga la string gzip. A continuación, se presenta un ejemplo de encabezados HTTP formados de manera correcta para habilitar la compresión gzip:
Accept-Encoding: gzip User-Agent: my program (gzip)
Trabaja con recursos parciales
Otra forma de mejorar el rendimiento de tus llamadas a la API es enviar y recibir solo la parte de los datos que te interesa. Esto permite que tu aplicación evite la transferencia, el análisis y el almacenamiento de campos innecesarios, por lo que pueda usar recursos como la red, la CPU y la memoria con más eficiencia.
Existen los siguientes dos tipos de solicitudes parciales:
- Respuesta parcial: una solicitud en la que especificas qué campos incluir en la respuesta (usa el parámetro de la solicitud de
fields). - Parche: una solicitud de actualización en la que envías solo los campos que deseas cambiar (usa el verbo HTTP
PATCH).
En las siguientes secciones, se proporcionan más detalles sobre cómo realizar solicitudes parciales.
Respuesta parcial
De forma predeterminada, el servidor muestra la representación completa de un recurso después de procesar las solicitudes. Para lograr un mejor rendimiento, puedes pedirle al servidor que envíe solo los campos que realmente necesitas y obtener una respuesta parcial en su lugar.
Si quieres solicitar una respuesta parcial, usa el parámetro de solicitud de fields para especificar los campos que deseas que se muestren. Puedes usar este parámetro con cualquier solicitud que muestre datos de respuesta.
Ten en cuenta que el parámetro de fields solo afecta a los datos de respuesta; no afecta a los datos que necesitas enviar, si los hay. Para reducir la cantidad de datos que envías cuando modificas recursos, usa una solicitud de parche.
Ejemplo
Parche (actualización parcial)
También puedes evitar el envío de datos innecesarios cuando modificas recursos. Si quieres enviar datos actualizados solo para los campos específicos que modificas, usa el verbo HTTP PATCH. La semántica de parches descrita en este documento es diferente (y más simple) de lo que era para la implementación anterior de GData de actualización parcial.
En el siguiente ejemplo, se muestra cómo el uso de un parche minimiza los datos que necesitas enviar para realizar una actualización pequeña.
Ejemplo
Controla la respuesta a un parche
Después de procesar una solicitud de parche válida, la API muestra un código de respuesta HTTP 200 OK junto con la representación completa del recurso modificado. Si la API usa ETags, el servidor actualiza los valores de ETag cuando procesa con éxito una solicitud de parche, al igual que lo hace con PUT.
La solicitud de parche muestra la representación de recursos completa, a menos que uses el parámetro de fields para reducir la cantidad de datos que se muestran.
Si una solicitud de parche genera un estado de recursos nuevo que no es válido de manera sintáctica o semántica, el servidor muestra un código de estado HTTP 400 Bad Requesto 422 Unprocessable Entity y el estado de recursos permanece igual. Por ejemplo, si intentas borrar el valor de un campo obligatorio, el servidor muestra un error.
Notación alternativa cuando no se admite el verbo HTTP PATCH
Si tu firewall no permite solicitudes HTTP PATCH, entonces haz una solicitud HTTP POST y configura el encabezado de anulación como PATCH, como se muestra a continuación:
POST https://www.googleapis.com/... X-HTTP-Method-Override: PATCH ...
Diferencia entre parche y actualización
En la práctica, cuando envías datos para una solicitud de actualización que usa el verbo HTTP PUT, solo necesitas enviar los campos obligatorios o los opcionales; si envías valores para los campos que establece el servidor, se ignoran. Aunque esto puede parecer otra forma de hacer una actualización parcial, este enfoque tiene algunas limitaciones. Con las actualizaciones que usan el verbo HTTP PUT, la solicitud falla si no proporcionas los parámetros obligatorios y borra los datos establecidos antes si no proporcionas los parámetros opcionales.
Por esta razón, es mucho más seguro usar un parche. Solo debes proporcionar datos para los campos que deseas cambiar; los campos que omites no se borran. La única excepción a esta regla se produce con la repetición de elementos o arreglos: si omites todos, se mantienen tal como están; si proporcionas alguno de ellos, todo el conjunto se reemplaza por el conjunto que proporciones.