Saltar al contenido principal
Este endpoint se ha actualizado para incluir metadatos de edición de Post. Obtén más información sobre estos metadatos en la página de fundamentos “Editar Posts”.

​
Decahose stream

Enterprise Esta es una API de Enterprise disponible únicamente dentro de nuestros niveles de acceso gestionados. Para usar esta API, primero debe configurar una cuenta con nuestro equipo de ventas de Enterprise. Más información Decahose entrega una muestra aleatoria del 10% del Firehose de X en tiempo real a través de una conexión de streaming. Esto se logra mediante un algoritmo de muestreo en tiempo real que selecciona los datos aleatoriamente, a la vez que permite la entrega de datos con la baja latencia esperada mientras X los envía a través del firehose. A continuación se presentan algunas de las características disponibles con Decahose:
  • URL ampliadas y mejoradas: - expande completamente las URL acortadas y proporciona metadatos adicionales (título y descripción de la página)
  • Particionado del stream - 2 particiones, cada una con el 50% del volumen del stream Decahose
  • Fiabilidad mejorada - diversidad geográfica de los sistemas de backend
Nota: Estos datos se entregan en bloque y no admiten filtrado adicional (p. ej., por palabras clave). ENTERPRISE

​
Transmisión de likes

Esta es una API de Enterprise disponible únicamente dentro de nuestros niveles de acceso gestionado. Para usar esta API, primero debe crear una cuenta con nuestro equipo de ventas de Enterprise. Más información Los likes permiten conocer quién marca con like los Posts y ofrecen conteos precisos de likes. Firehose y Decahose de Gnip pueden entregar likes públicos relacionados con los Posts suministrados a través de Gnip. Esto proporciona engagement público en tiempo real y metrics de audiencia asociadas con un Post.   Primeros pasos con Likes Al prepararse para consumir data de likes, debe saber que:
  • Los likes se entregan mediante un stream independiente
  • Históricamente, a los likes se les ha llamado “Favorites”. La carga útil en formato nativo enriquecido mantiene esta nomenclatura
  • Los streams incluyen únicamente likes públicos
    • Público significa que el usuario que da el like, el creador del Post y el Post son públicos en la plataforma
  • Los likes son muy similares a los Retweets y representan una señal pública de engagement
  • Los elementos de la carga útil incluyen:
    • Objeto de Post original
    • Objeto Actor que creó el Post original
    • Objeto Actor que realizó la acción de like
  • Solo se puede dar like al contenido original
    • No se pueden dar likes a los Retweets. Un like a un Retweet se aplica al Post original
    • Los Tweets citados se pueden dar like
  • Las actividades de like incluyen los Gnip Enrichments aplicables (cuando se hayan adquirido/aplicado)
  • Productos / Funciones compatibles
    • Los streams de likes admiten Backfill (cuando se haya adquirido/aplicado)
    • No hay compatibilidad con Replay para streams de likes
    • No hay compatibilidad con Search o Historical para likes
    • No hay planes inmediatos de agregar compatibilidad de likes a PowerTrack
Decahose Carga útil en formato nativo enriquecido 
{
   "id":"43560406e0ad9f68374445f5f30c33fc",
   "created_at":"Thu Dec 01 22:27:39 +0000 2016",
   "timestamp_ms":1480631259353,
   "favorited_status":{
      "created_at":"Thu Dec 01 22:27:16 +0000 2016",
      "id":804451830033948672,
      "id_str":"804451830033948672",
      "text":"@kafammheppduman",
      "source":"\u003ca href=\"http:\/\/x.com\/download\/android\" rel=\"nofollow\"\u003eX para Android\u003c\/a\u003e",
      "truncated":false,
      "in_reply_to_status_id":803694205163814912,
      "in_reply_to_status_id_str":"803694205163814912",
      "in_reply_to_user_id":2855759795,
      "in_reply_to_user_id_str":"2855759795",
      "in_reply_to_screen_name":"kafammheppduman",
      "user":{
         "id":2855759795,
         "id_str":"2855759795",
         "name":"delirdim kanka",
         "screen_name":"kafammheppduman",
         "location":"sanane",
         "url":"http:\/\/instagram.com\/kafammheppduman",
         "description":"Manit @GalatasaraySk \ud83d\udc9e",
         "translator_type":"none",
         "protected":false,
         "verified":false,
         "followers_count":3702,
         "friends_count":607,
         "listed_count":1,
         "favourites_count":113338,
         "statuses_count":389,
         "created_at":"Sat Nov 01 22:38:25 +0000 2014",
         "utc_offset":null,
         "time_zone":null,
         "geo_enabled":true,
         "lang":"tr",
         "contributors_enabled":false,
         "is_translator":false,
         "profile_background_color":"C0DEED",
         "profile_background_image_url":"",
         "profile_background_image_url_https":"",
         "profile_background_tile":false,
         "profile_link_color":"1DA1F2",
         "profile_sidebar_border_color":"C0DEED",
         "profile_sidebar_fill_color":"DDEEF6",
         "profile_text_color":"333333",
         "profile_use_background_image":true,
       "Profile_image_url": "http:\/\/pbs.twimg.com\/profile_images\/804421763945861121\/v3bp9pnq_normal.jpg",
         "Profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/804421763945861121\/v3bp9pnq_normal.jpg",
         "profile_banner_url":"https:\/\/pbs.twimg.com\/profile_banners\/2855759795\/1480630085",
         "default_profile":true,
         "default_profile_image":false,
         "following":null,
         "follow_request_sent":null,
         "notifications":null
      },
      "geo":null,
      "coordinates":null,
      "place":null,
      "contributors":null,
      "is_quote_status":false,
      "retweet_count":0,
      "favorite_count":0,
      "entities":{
         "hashtags":[],
         "urls":[],
         "user_mentions":[
            {
               "screen_name":"kafammheppduman",
               "name":"delirdim kanka",
               "id":2855759795,
               "id_str":"2855759795",
               "indices":[
                  0,
                  16
               ]
            }
         ],
         "symbols":[]
      },
      "favorited":false,
      "retweeted":false,
      "filter_level":"low",
      "lang":"und"
   },
   "user":{
      "id":774146932365070336,
      "id_str":"774146932365070336",
      "name":"Uyuyan Adam",
      "screen_name":"saykoMenn",
      "location":"Tarsus, T\u00fcrkiye",
      "url":"http:\/\/connected2.me\/pmc1i",
      "description":null,
      "translator_type":"none",
      "protected":false,
      "verified":false,
      "followers_count":414,
      "friends_count":393,
      "listed_count":0,
      "favourites_count":9868,
      "statuses_count":370,
      "created_at":"Fri Sep 09 07:26:26 +0000 2016",
      "utc_offset":null,
      "time_zone":null,
      "geo_enabled":false,
      "lang":"tr",
      "contributors_enabled":false,
      "is_translator":false,
      "profile_background_color":"F5F8FA",
      "profile_background_image_url":"",
      "profile_background_image_url_https":"",
      "profile_background_tile":false,
      "profile_link_color":"1DA1F2",
      "profile_sidebar_border_color":"C0DEED",
      "profile_sidebar_fill_color":"DDEEF6",
      "profile_text_color":"333333",
      "profile_use_background_image":true,
      "Profile_image_url": "http:\/\/pbs.twimg.com\/profile_images\/802992813424201728\/VMzcTL3x_normal.jpg",
      "Profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/802992813424201728\/VMzcTL3x_normal.jpg",
      "profile_banner_url":"https:\/\/pbs.twimg.com\/profile_banners\/774146932365070336\/1480283382",
      "default_profile":true,
      "default_profile_image":false,
      "following":null,
      "follow_request_sent":null,
      "notifications":null
   }
}
Carga útil de Like DELETE / “Unlike” 
{
   "delete":{
      "favorite":{
         "tweet_id":696615514970279937,
         "tweet_id_str":"696615514970279937",
         "user_id":2510287578,
         "user_id_str":"2510287578"
      },
      "timestamp_ms":"1480437031205"
   }
}

​
Guías

​
Recuperación y redundancia

Introducción  Con la transmisión de altos volúmenes de Posts en tiempo real viene un conjunto de prácticas recomendadas que promueven tanto la confiabilidad de los datos como su fidelidad íntegra. Al consumir datos en tiempo real, maximizar el tiempo de conexión es un objetivo fundamental. Cuando se produzcan desconexiones, es importante detectarlas automáticamente y volver a conectarse. Tras reconectarse, es importante evaluar si hay periodos para los que se deba realizar backfill de datos. El componente que gestiona estos detalles y consume Posts en tiempo real es solo una parte de un sistema con consideraciones de red, datastore, servidor y almacenamiento. Dada la complejidad de estos sistemas, otra práctica recomendada es disponer de diferentes entornos de transmisión, con al menos streams separados para desarrollo/pruebas y producción. Decahose incluye un conjunto de funciones que ayudan en estos esfuerzos.
  1. Para admitir múltiples entornos, podemos implementar Additional Streams para su cuenta. Estos streams son independientes entre sí y tienen una stream_label diferente para ayudar a diferenciarlos.
  2. Para ayudar a mantener una conexión, cada stream de Decahose admite Redundant Connections. La arquitectura más común es que un stream tenga dos conexiones y, en el lado del cliente, haya dos consumidores independientes, idealmente en redes diferentes. Con este diseño, puede haber redundancia en las redes del lado del cliente, los servidores y las rutas del datastore. Tenga en cuenta que se sirve una copia completa de los datos en cada conexión y el lado del cliente debe ser tolerante y gestionar datos duplicados.
  3. Se proporcionará un “heartbeat” cada 10 segundos; sin embargo, con el stream de Decahose, el volumen de datos es lo suficientemente alto como para que incluso una breve duración (p. ej., unos segundos) sin Posts pueda indicar un problema de conexión. Por lo tanto, tanto un “silencio de datos” como la falta de un heartbeat pueden usarse para detectar una desconexión.
Dado que las desconexiones ocurrirán, el stream de Decahose cuenta con funciones dedicadas de Recovery y Backfill para ayudar a recuperar los datos que se perdieron debido a desconexiones y otros problemas operativos.

​
Streams adicionales

Contar con streams de Decahose adicionales es otra forma de incorporar confiabilidad a su solución. Cada stream adicional es completamente independiente y tiene su propio endpoint. A cada stream se le asigna su propio stream_label, y esta etiqueta, junto con el nombre de su cuenta, forman parte de la URL de ese stream. Vea el siguiente ejemplo: https://gnip-stream.x.com/stream/sample10/accounts/:account_name/publishers/twitter/:stream_label.json La convención más común es tener un stream en tiempo real dedicado a su sistema de producción y un stream adicional disponible para desarrollo y pruebas. Contar con un stream de prueba/desarrollo permite a los clientes de Decahose disponer de un stream para validar actualizaciones de sus consumidores cliente. Si bien se puede asignar cualquier etiqueta (única) a un stream, una convención es usar ‘prod’ para el stream de producción y ‘dev’ o ‘sandbox’ para un stream de desarrollo adicional. La cantidad de streams y sus etiquetas únicas es configurable por su representante de cuenta. Conexiones redundantes Una conexión redundante simplemente le permite establecer más de una conexión simultánea al stream de datos. Esto proporciona redundancia al permitirle conectarse al mismo stream con dos consumidores separados, recibiendo los mismos datos a través de ambas conexiones. Así, su App cuenta con conmutación por error en caliente para diversas situaciones, por ejemplo, cuando un stream se desconecta o cuando falla el servidor principal de su App. La cantidad de conexiones permitidas para un stream determinado es configurable por su representante de cuenta. Para usar un stream redundante, simplemente conéctese a la misma URL utilizada para su conexión principal. Los datos de su stream se enviarán a través de ambas conexiones, y ambas conexiones de stream se reflejarán en el panel del stream. Tenga en cuenta que, para fines de facturación, deduplicamos los conteos de actividad que recibe a través de múltiples conexiones, de modo que solo se le cobre una vez por cada actividad única. Dado que Decahose tiene dos particiones, a continuación se muestra un ejemplo de cómo funciona el conteo de conexiones: Connect to decahose partition=1 Connect to decahose partition=1 Connect to decahose partition=2 La situación anterior produce un total de tres conexiones: dos conexiones a partition=1 y una conexión a partition=2. Normalmente, querrá el mismo número de conexiones en cada partición, por lo que este ejemplo destaca una situación en la que la conexión redundante a partition=2 se ha caído y desea investigarla más a fondo. Recuperación

​
Descripción general 

Recovery es una herramienta de recuperación de datos (no debe utilizarse para la recolección principal de datos) que ofrece acceso por streaming a una ventana continua de 5 días de datos históricos recientes de X. Debe emplearse para recuperar datos en situaciones en las que tu aplicación consumidora pierda datos en el stream en tiempo real, ya sea por una desconexión breve o por cualquier otro motivo que impida la ingesta de datos en tiempo real durante un período.

​
Uso de Recovery 

Con el stream de Recovery, su App puede realizar solicitudes que funcionan del mismo modo que las solicitudes a los streams en tiempo real. Sin embargo, su App debe especificar parámetros en la URL que indiquen la ventana de tiempo solicitada. En otras palabras, una solicitud de Recovery le pide a la API “Posts desde la hora A hasta la hora B”. Estos Posts se entregan a través de su conexión de streaming de una manera que imita el stream en tiempo real, pero a una velocidad ligeramente inferior a la del tiempo real. Consulte el siguiente ejemplo: “https://stream-data-api.x.com/stream/powertrack/accounts/someAccountName/publishers/twitter/powertrack.json?startTime=2023-07-05T17:09:12.070Z” Los Posts se entregan comenzando por el primer (más antiguo) minuto del período de tiempo especificado y continúan de forma cronológica hasta que se entregue el último minuto. En ese punto, se envía un mensaje de “Recovery Request Completed” a través de la conexión y, a continuación, el servidor cierra la conexión. Si su solicitud comienza en un momento del día en el que hubo pocos o ningún resultado coincidente, probablemente transcurra un período de tiempo antes de que se entreguen los primeros resultados; los datos se entregarán cuando Recovery encuentre coincidencias en la parte del archivo que se esté procesando en ese momento. Cuando no haya resultados disponibles para entregar, el stream seguirá enviando retornos de carro, o “latidos” (heartbeats), a través de la conexión para evitar que su sesión agote el tiempo de espera. Recovery está pensado como una herramienta para recuperar con facilidad datos perdidos debido a desconexiones breves, no para períodos muy largos como un día completo. Si surge la necesidad de recuperar datos durante períodos prolongados, recomendamos dividir las solicitudes más largas en ventanas de tiempo más cortas (p. ej., dos horas) para reducir la posibilidad de que se produzca una desconexión a mitad de la solicitud debido a la volatilidad de internet u otros motivos, y para proporcionar mayor visibilidad del progreso de solicitudes largas.

​
Disponibilidad de datos

Puede usar la función Recovery para recuperar datos perdidos en las últimas 24 horas si no puede volver a conectarse dentro de la ventana de backfill de 5 minutos. La función de recuperación de streaming le permite disponer de una ventana de backfill ampliada de 24 horas. Recovery le permite “recuperar” el periodo de tiempo con datos perdidos. Se inicia un stream de recuperación cuando realiza una solicitud de conexión usando los parámetros de solicitud ‘start_time’ y ‘end_time’. Una vez conectado, Recovery volverá a hacer stream del periodo indicado y luego se desconectará. Podrá realizar 2 solicitudes concurrentes a Recovery al mismo tiempo, es decir, “dos trabajos de recuperación”. Recovery funciona técnicamente de la misma manera que backfill, excepto que se define una hora de inicio y una hora de finalización. Un periodo de recuperación corresponde a un único intervalo de tiempo.

​
Backfill

Para solicitar backfill, debes agregar el parámetro backfillMinutes=N a tu solicitud de conexión, donde N es la cantidad de minutos (1-5, solo números enteros) que se recuperarán cuando se establezca la conexión. Por ejemplo, si te desconectas durante 90 segundos, debes agregar backfillMinutes=2 a tu solicitud de conexión. Dado que esta solicitud proporcionará backfill durante 2 minutos, incluido el período de 30 segundos anterior a tu desconexión, tu App consumidora debe tolerar datos duplicados. Un ejemplo de URL de solicitud de conexión de Decahose, pidiendo un backfill de 5 minutos para la partición 1, es: https://gnip-stream.x.com/stream/sample10/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1&backfillMinutes=5 NOTAS:
  • Tienes la opción de usar siempre “backfillMinutes=5” al conectarte y luego manejar cualquier dato duplicado que se proporcione.
  • Si estás desconectado por más de cinco minutos, puedes recuperar datos usando Recovery.
Recuperación tras una desconexión Reiniciar y recuperarse de una desconexión implica varios pasos:
  • Determinar la duración del período de desconexión.
    • ¿5 minutos o menos?
      • Si tienes Backfill habilitado para el stream, prepara la solicitud de conexión con el parámetro “backfillMinutes” apropiado.
    • ¿Más de 5 minutos?
      • Si tienes un stream de Recovery, realiza una solicitud de Recovery para el período desconectado (idealmente con tu conjunto de reglas de tiempo real actual, usando la Rules API si es necesario).
  • Solicitar una nueva conexión.
Cuando experimentes desconexiones o tiempo de inactividad, aquí tienes estrategias para mitigar y recuperarte en este escenario:
  1. Implementar backfill Backfill te permite reconectarte desde un punto anterior a la desconexión de un stream y cubre interrupciones de hasta 5 minutos. Se implementa incluyendo un parámetro en la solicitud de conexión.
  2. Consumir un stream redundante desde otra ubicación Si el stream redundante puede transmitirse al mismo entorno en vivo, con desduplicación de datos, eliminarás la necesidad de recuperación a menos que TANTO el stream normal como el redundante sufran simultáneamente tiempo de inactividad o desconexiones. Si el stream redundante no puede transmitirse en vivo al entorno de producción, puede volcarse en un almacén de datos “de emergencia” separado. Entonces, en caso de desconexiones o tiempo de inactividad en la conexión del stream principal, tu sistema tendrá datos a mano para completar tu base de datos principal durante el período en que falten datos.
  3. Implementar Recovery Cuando las desconexiones o el tiempo de inactividad afecten tanto al stream principal como al stream redundante, usa Decahose Recovery para recuperar cualquier dato perdido. La API proporciona una ventana móvil que cubre 5 días del archivo y se aprovecha mejor solicitando no más de una hora de esa ventana por solicitud y transmitiéndola. Esto se hace en paralelo al stream en tiempo real. Ten en cuenta que no tenemos soluciones para recuperar datos de Decahose más allá de la ventana de 5 días que ofrece Recovery, por lo que es importante utilizar un stream redundante para asegurarte de tener una copia completa de los datos de tu lado en caso de un tiempo de inactividad significativo.
Cuando detectes volúmenes anómalos de datos almacenados: Formas posibles de detectar datos faltantes cuando no hubo desconexiones ni tiempo de inactividad…
  1. Contar los Posts entrantes Tu sistema debe contar el número bruto de Posts que recibes al inicio de tu App de ingesta y luego proporcionar una forma de comparar esos números con el número de Posts que llegan a tu almacén de datos final. Cualquier diferencia puede monitorearse y alertar a tu equipo sobre problemas que provoquen la pérdida de datos después de ser recibidos.
  2. Analizar volúmenes almacenados anómalos También puedes analizar los volúmenes de datos almacenados en tu base de datos final para buscar caídas anómalas. Esto también puede indicar problemas, aunque probablemente habrá circunstancias en las que las caídas de volumen sean normales (p. ej., si la plataforma X no está disponible y las personas no pueden crear Posts durante algún período).

​
Referencia de API

​
Stream Decahose

Ir a esta página Métodos Autenticación GET /{stream-type}/:stream API de Replay

​
Métodos

MétodoDescripción
GET /{stream-type}/:streamConectar al stream de datos

​
Autenticación

Todas las solicitudes a las APIs de Volume Stream deben usar autenticación básica de HTTP, construida a partir de una combinación válida de dirección de correo electrónico y contraseña utilizada para iniciar sesión en su cuenta en console.gnip.com. Las credenciales deben enviarse en el encabezado Authorization en cada solicitud. Por lo tanto, confirme que su cliente esté agregando el encabezado HTTP “Authorization: Basic” (con las credenciales codificadas sobre HTTPS) a todas las solicitudes a la API.

​
GET :stream

Establece una conexión persistente con el stream Firehose, por la cual se entregarán los datos en tiempo real.

​
Especificaciones de la solicitud

Método de la solicitudHTTP GET
Tipo de conexiónKeep-Alive

Esto debe especificarse en el encabezado de la solicitud.
URLDisponible en la página de ayuda de la API del stream en su panel de control, con la siguiente estructura:

Decahose:

https://gnip-stream.x.com/stream/sample10/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1
Partición (obligatorio)partition=\{#} - Ahora se requiere la partición para consumir el stream completo. Deberá conectarse al stream con el parámetro de partición especificado. A continuación se muestra el número de particiones por stream:

* Decahose: 2 particiones
CompresiónGzip. Para conectarse al stream usando compresión Gzip, envíe un encabezado Accept-Encoding en la solicitud de conexión. El encabezado debe tener el siguiente formato:

Accept-Encoding: gzip
Codificación de caracteresUTF-8
Formato de respuestaJSON. El encabezado de su solicitud debe especificar el formato JSON para la respuesta.
Límite de tasa10 solicitudes por 60 segundos.
Parámetro BackfillSi ha adquirido un stream con Backfill habilitado, deberá agregar el parámetro “backfillMinutes” en la solicitud GET para habilitarlo.
Tiempo de espera de lecturaConfigure un tiempo de espera de lectura en su cliente y asegúrese de que esté establecido en un valor superior a 30 segundos.
Compatibilidad con ediciones de TweetTodos los objetos de Tweet incluirán metadatos de edición de Tweet que describen el historial de ediciones del Tweet. Consulte la página de fundamentos “Edit Tweets” para más detalles.

​
Respuestas

La API puede devolver las siguientes respuestas para estas solicitudes. La mayoría de los códigos de error se devuelven con una cadena que incluye detalles adicionales en el cuerpo. Para respuestas que no sean 200, los clientes deben intentar reconectarse.
EstadoTextoDescripción
200CorrectoLa conexión se abrió correctamente y se enviarán nuevas actividades a medida que lleguen.
401No autorizadoLa autenticación HTTP falló debido a credenciales no válidas. Inicia sesión en console.gnip.com con tus credenciales para confirmar que las estás usando correctamente en tu solicitud.
406No aceptableGeneralmente, esto ocurre cuando tu cliente no incluye correctamente los encabezados para aceptar la codificación gzip del stream, aunque también puede ocurrir en otras circunstancias.

Contendrá un mensaje JSON similar a: “Esta conexión requiere compresión. Para habilitar la compresión, envía un encabezado ‘Accept-Encoding: gzip’ en tu solicitud y prepárate para descomprimir el stream a medida que se lea en el lado del cliente.”
429Límite de tasa excedidoTu App ha superado el límite de solicitudes de conexión.
503Servicio no disponibleProblema en el servidor de Twitter. Vuelve a conectarte usando un patrón de backoff exponencial. Si no se ha publicado ningún aviso sobre este problema en la X API Status Page, contacta al soporte o a emergencias si no puedes conectarte después de 10 minutos.

​
Ejemplo de solicitud con curl

La siguiente solicitud de ejemplo se realiza con cURL desde la línea de comandos. No obstante, tenga en cuenta que estas solicitudes también pueden enviarse con el lenguaje de programación de su preferencia: 
curl --compressed -v -uexample@customer.com "https://gnip-stream.x.com/stream/firehose/accounts/:account\_name/publishers/twitter/:stream\_label.json?partition={#}"

​
API de Replay

La API de Replay es un complemento importante de los streams de volumen en tiempo real. Replay es una herramienta de recuperación de datos que ofrece acceso en stream a una ventana deslizante de datos históricos recientes de X.
⌘I