L’interface HTTP vous permet D’utiliser ClickHouse sur n’importe quelle plate-forme à partir de n’importe quel langage de programmation. Nous l’utilisons pour travailler à partir de Java et Perl, ainsi que des scripts shell. Dans d’autres départements, L’interface HTTP est utilisée à partir de Perl, Python et Go. L’interface HTTP est plus limitée que l’interface native, mais elle a une meilleure compatibilité.
Si vous faites une requête GET / sans Paramètres, elle renvoie le code de réponse 200 et la chaîne définie dans [http\_server\_default\_response](../operations/server-configuration-parameters/settings.md#server_configuration_parameters-http_server_default_response) valeur par défaut “Ok.” (avec un saut de ligne à la fin)
Utilisez la requête GET /ping dans les scripts de vérification de la santé. Ce gestionnaire revient toujours “Ok.” (avec un saut de ligne à la fin). Disponible à partir de la version 18.12.13.
Envoyer la demande sous forme D’URL ‘query’ paramètre, ou comme un POSTE. Ou envoyer le début de la requête dans l’‘query’ paramètre, et le reste dans le POST (nous expliquerons plus tard pourquoi cela est nécessaire). La taille de L’URL est limitée à 16 Ko, alors gardez cela à l’esprit lors de l’envoi de requêtes volumineuses.
Lorsque vous utilisez la méthode GET, ‘readonly’ est définie. En d’autres termes, pour les requêtes qui modifient les données, vous ne pouvez utiliser que la méthode POST. Vous pouvez envoyer la requête elle-même dans le corps du message ou dans le paramètre URL.
Bien que wget échappe à tout lui-même, nous ne recommandons pas de l’utiliser car il ne fonctionne pas bien sur HTTP 1.1 lors de l’utilisation de keep-alive et Transfer-Encoding: chunked.
Si une partie de la requête est envoyée dans le paramètre et une partie dans la publication, un saut de ligne est inséré entre ces deux parties de données.
La méthode POST de transmission des données est nécessaire pour les requêtes INSERT. Dans ce cas, vous pouvez écrire le début de la requête dans le paramètre URL et utiliser POST pour transmettre les données à insérer. Les données à insérer pourraient être, par exemple, un vidage séparé par tabulation de MySQL. De cette façon, la requête INSERT remplace LOAD DATA LOCAL INFILE de MySQL.
Vous pouvez spécifier n’importe quel format de données. Le ‘Values’ le format est le même que ce qui est utilisé lors de L’écriture INSERT dans les valeurs t:
Vous pouvez utiliser le format de compression ClickHouse interne lors de la transmission de données. Les données compressées ont un format non standard, et vous devrez utiliser le spécial `clickhouse-compressor` programme de travail (il s’est installé avec le `clickhouse-client` paquet). Pour augmenter l’efficacité de l’insertion de données, vous pouvez désactiver la vérification de la somme de contrôle côté serveur en utilisant [http\_native\_compression\_disable\_checksumming\_on\_decompress](../operations/settings/settings.md#settings-http_native_compression_disable_checksumming_on_decompress) paramètre.
Vous pouvez également choisir d’utiliser [La compression HTTP](https://en.wikipedia.org/wiki/HTTP_compression). Pour envoyer un compressé `POST` demande, ajouter l’en-tête de requête `Content-Encoding: compression_method`. Pour que ClickHouse compresse la réponse, vous devez ajouter `Accept-Encoding: compression_method`. Supports ClickHouse `gzip`, `br`, et `deflate` [méthodes de compression](https://en.wikipedia.org/wiki/HTTP_compression#Content-Encoding_tokens). Pour activer la compression HTTP, vous devez utiliser le ClickHouse [enable\_http\_compression](../operations/settings/settings.md#settings-enable_http_compression) paramètre. Vous pouvez configurer le niveau de compression des données dans le [http\_zlib\_compression\_level](#settings-http_zlib_compression_level) pour toutes les méthodes de compression.
Vous pouvez l’utiliser pour réduire le trafic réseau lors de la transmission d’une grande quantité de données, ou pour créer des vidages qui sont immédiatement compressés.
Certains clients HTTP peuvent décompresser les données du serveur par défaut (avec `gzip` et `deflate`) et vous pouvez obtenir des données décompressées même si vous utilisez les paramètres de compression correctement.
Par défaut, la base de données enregistrée dans les paramètres du serveur est utilisée comme base de données par défaut. Par défaut, c’est la base de données appelée ‘default’. Alternativement, vous pouvez toujours spécifier la base de données en utilisant un point avant le nom de la table.
Si le nom d’utilisateur n’est spécifié, le `default` le nom est utilisé. Si le mot de passe n’est spécifié, le mot de passe vide est utilisé.
Vous pouvez également utiliser les paramètres D’URL pour spécifier des paramètres pour le traitement d’une seule requête ou de profils entiers de paramètres. Exemple: http: / / localhost: 8123/?profil = web & max\_rows\_to\_read=1000000000 & query=sélectionner + 1
De même, vous pouvez utiliser des sessions ClickHouse dans le protocole HTTP. Pour ce faire, vous devez ajouter l’`session_id` GET paramètre à la demande. Vous pouvez utiliser n’importe quelle chaîne comme ID de session. Par défaut, la session est terminée après 60 secondes d’inactivité. Pour modifier ce délai d’attente, de modifier la `default_session_timeout` dans la configuration du serveur, ou ajoutez le `session_timeout` GET paramètre à la demande. Pour vérifier l’état de la session, utilisez `session_check=1` paramètre. Une seule requête à la fois peut être exécutée dans une seule session.
Vous pouvez recevoir des informations sur le déroulement d’une requête en `X-ClickHouse-Progress` en-têtes de réponse. Pour ce faire, activez [send\_progress\_in\_http\_headers](../operations/settings/settings.md#settings-send_progress_in_http_headers). Exemple de l’en-tête de séquence:
Les requêtes en cours d’exécution ne s’arrêtent pas automatiquement si la connexion HTTP est perdue. L’analyse et le formatage des données sont effectués côté serveur et l’utilisation du réseau peut s’avérer inefficace.
Facultatif ‘query\_id’ le paramètre peut être passé comme ID de requête (n’importe quelle chaîne). Pour plus d’informations, consultez la section “Settings, replace\_running\_query”.
Facultatif ‘quota\_key’ le paramètre peut être passé comme clé de quota (n’importe quelle chaîne). Pour plus d’informations, consultez la section “Quotas”.
L’interface HTTP permet de transmettre des données externes (tables temporaires externes) pour l’interrogation. Pour plus d’informations, consultez la section “External data for query processing”.
Vous pouvez activer la mise en mémoire tampon des réponses côté serveur. Le `buffer_size` et `wait_end_of_query` Les paramètres D’URL sont fournis à cette fin.
`buffer_size` détermine le nombre d’octets dans le résultat de tampon dans la mémoire du serveur. Si un corps de résultat est supérieur à ce seuil, le tampon est écrit sur le canal HTTP et les données restantes sont envoyées directement au canal HTTP.
Pour vous assurer que la réponse entière est mise en mémoire tampon, définissez `wait_end_of_query=1`. Dans ce cas, les données ne sont pas stockées dans la mémoire tampon temporaire du serveur de fichiers.
Exemple:
``` bash
$ curl -sS 'http://localhost:8123/?max_result_bytes=4000000&buffer_size=3000000&wait_end_of_query=1' -d 'SELECT toUInt8(number) FROM system.numbers LIMIT 9000000 FORMAT RowBinary'
Utilisez la mise en mémoire tampon pour éviter les situations où une erreur de traitement de requête s’est produite après l’envoi du code de réponse et des en-têtes HTTP au client. Dans cette situation, un message d’erreur est écrit à la fin du corps de la réponse, et du côté client, l’erreur ne peut être détectée qu’à l’étape d’analyse.
Vous pouvez créer une requête avec paramètres et transmettre des valeurs des paramètres de la requête HTTP. Pour plus d’informations, voir [Requêtes avec des paramètres pour CLI](cli.md#cli-queries-with-parameters).
ClickHouse prend également en charge L’Interface HTTP prédéfinie qui peut vous aider à une intégration plus facile avec des outils tiers tels que [Prometheus exportateur](https://github.com/percona-lab/clickhouse_exporter).
Comme vous pouvez le voir dans l’exemple, si `<http_handlers>` est configuré dans la configuration.fichier xml, ClickHouse fera correspondre les requêtes HTTP reçues au type prédéfini dans `<http_handlers>`, puis ClickHouse exécutera la requête prédéfinie correspondante si la correspondance est réussie.
`<root_handler>` renvoie le contenu spécifié pour la requête de chemin racine. Le contenu de retour spécifique est configuré par `http_server_default_response` dans la configuration.XML. si non spécifié, le retour **OK.**
`<ping_handler>` peut être utilisé pour sonder la santé du serveur clickhouse actuel. Lorsque le serveur HTTP ClickHouse est normal, l’accès à ClickHouse via `<ping_handler>` sera de retour **OK.**.
`<replicas_status_handler>` est utilisé pour détecter l’état du nœud de réplica et le retour **OK.** si le nœud réplique n’a pas de délai. S’il y a un retard, renvoyez le retard spécifique. La valeur de `<replicas_status_handler>` prend en charge la personnalisation. Si vous ne spécifiez pas `<replicas_status_handler>`, ClickHouse réglage par défaut `<replicas_status_handler>` être **/ replicas\_status**.
`<method>` est responsable de la correspondance de la partie méthode de la requête HTTP. `<method>` entièrement conforme à la définition de [méthode](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods) dans le protocole HTTP. C’est une option de configuration. S’il n’est pas défini dans le fichier de configuration, il ne correspond pas à la partie méthode de la requête HTTP
`<url>` est responsable de la correspondance de la partie url de la requête HTTP. Il est compatible avec [RE2](https://github.com/google/re2)s ’expressions régulières. C’est une option de configuration. S’il n’est pas défini dans le fichier de configuration, il ne correspond pas à la partie url de la requête HTTP
`<headers>` est responsable de la correspondance de la partie d’en-tête de la requête HTTP. Il est compatible avec les expressions régulières de RE2. C’est une option de configuration. S’il n’est pas défini dans le fichier de configuration, il ne correspond pas à la partie d’en-tête de la requête HTTP
`<queries>` la valeur est une requête prédéfinie de `<predefined_query_handler>`, qui est exécuté par ClickHouse lorsqu’une requête HTTP est mise en correspondance et que le résultat de la requête est renvoyé. C’est une configuration incontournable.
L’exemple suivant définit les valeurs de `max_threads` et `max_alter_threads` Paramètres, puis interroge la table système pour vérifier si ces paramètres ont été définis avec succès.
Clickhouse extrait et exécute la valeur correspondant au `<query_param_name>` valeur dans l’url de la requête HTTP.
ClickHouse réglage par défaut `<query_param_name>` être `/query` . C’est une option de configuration. Si il n’y a pas de définition dans le fichier de configuration, le paramètre n’est pas passé.
Pour expérimenter cette fonctionnalité, l’exemple définit les valeurs de max\_threads et max\_alter\_threads et demande si les paramètres ont été définis avec succès.
La différence est que dans `<predefined_query_handler>`, la requête est écrite dans le fichier de configuration. Mais dans `<dynamic_query_handler>`, la requête est écrite sous la forme de param de la requête HTTP.
