Fonctionnalité des points de terminaison de l'API
Workflow des points de terminaisons
La section décrit le processus global de catégorisation des points de terminaison d'API pour échanger des données.
Envoi d'une demande au terminal
Le « client » (une application ou un système tiers) envoie une requête HTTP aux terminaux. La demande inclut des informations spécifiques (entrées).
Exemple : Demande pour
GetCategorybash POST https://api.olfeo.com/v1/GetCategory content-Type : application/json { "url": "https://example.com" }Traitement des entrées sur le serveur
Une fois que le terminal reçoit une demande, le serveur exécute les étapes suivantes :
Validation : le serveur vérifie les entrées (par exemple, le format de l'URL, la longueur des données, le type de données attendu),
Transformation : si nécessaire, les entrées sont transformées (par exemple, normalisation des URL, suppression des caractères inutiles),
Logique métier : le serveur exécute la logique associée à un point de terminaison, par exemple en interrogeant une base de données pour déterminer la catégorie de l'URL donnée.
Envoi d'une réponse au client
Le serveur renvoie une réponse structurée au client. La réponse comprend généralement les éléments suivants :
Données relatives aux résultats : par exemple, la catégorie associée à l'URL.
Codes d'état HTTP : indiquer le résultat de la demande (par exemple,
200 OK: La demande a été acceptée,400 Bad Request: Entrée non valide,500 Internal Server Error: Erreur côté serveur).
Exemple : Réponse pour
GetCategoryjson { "url" : "https://example.com", "categories" : ["News", "Technology"] }
En savoir plus sur la validation et la transformation des entrées
La validation est le processus qui permet de s'assurer que les données d'entrée sont conformes à des critères ou à des contraintes spécifiques avant d'être traitées par un système. Cela inclut la vérification du type, du format, de la plage et de la taille des données afin de s'assurer qu'elles répondent à des règles prédéfinies. L'objectif est de garantir que seules des données exactes et acceptables (domaines ou adresses IP) sont transmises pour un traitement ultérieur.
D'autre part, la transformation fait référence à la modification ou à la mise en forme des données d'entrée afin de les aligner sur les exigences internes du système. Ce processus peut impliquer la normalisation et l'adaptation des données aux besoins.
Ensemble, la validation et la transformation garantissent que les données d'entrée sont prêtes à être traitées, réduisant ainsi les risques tels que les vulnérabilités, les erreurs ou les sorties incorrectes.
Exemples pratiques : Validation et transformation des entrées
Cette section présente un tableau d'exemples illustrant la manière dont le système valide et transforme les données d'entrée sous diverses contraintes.

Gestion de la validation des entrées
Longueur < 255 caractères
Cette validation garantit que la longueur totale d'un domaine, y compris toutes ses étiquettes et ses points de séparation, ne dépasse pas 255 caractères, ce qui est le maximum autorisé par le protocole DNS. La limite de longueur est essentielle car elle garantit que les noms de domaine restent gérables et résolvables sur tous les systèmes DNS. Par exemple, un domaine tel que [
wignlgwivylydhyragcqbzoxmxhpdarbbjwaxtggyfjuhktsmqyorjqahtlquwa.slcrpmzbarcmkjjjjihyhxnanbqaplntfrlamqgftmogfmqqhghkjxvfsdedkkh.gtlmneotooiwyjzupughmlxdobqbijquczinncjclaugmdkawplwbzpvdajrjqs.hahkflakcoxoncnkenhrhihhmbkpcdubhksbburkmbnrztgmrkknacgzsxhogfo.com] dépasse la longueur autorisée et serait rejetée par le système. L'API répond par une erreur telle que le code :invalid_argument,message:domain length > 255`. Cette vérification est nécessaire pour maintenir la conformité aux normes DNS et pour éviter que des noms de domaine trop longs ne nuisent au système.Chaque étiquette ne comporte pas plus de 63 caractères
Chaque étiquette d'un domaine (un segment du nom de domaine entre des points, tel que « www », « example » ou « com ») ne doit pas dépasser 63 caractères. Il s'agit d'une autre exigence du protocole DNS pour garantir la compatibilité et la fiabilité. Par exemple, le domaine [
mrqzetqtkivbzngbhoiaznktkbcmceemtbtumtsjyapi.com] possède une étiquette (c'est-à-dire,mrqzetqtkivbzngbhoiaznktkbcmceemtbtumtsjyapi) qui dépasse cette limite. Par conséquent, le système rejette le domaine et renvoie une erreur telle que le code :invalid_argument,message:idna: invalid label. Cette étape garantit que tous les composants du domaine sont bien formés et valides
Gestion de la transformation des entrées
Longueur <= 253 sans le point de fin
Cette transformation garantit que les domaines sont tronqués à une longueur maximale de 253 caractères après suppression des points de fin. Un point final, comme dans [
flbydawyqbxacdhfiknlpwwdxaswuxuraioxskrbzvijszsijbldlygxcnvcrze.lgrxgpunojzrftspdquunnuzdspfgeifkipjmjeueiysysgsuufzklxowenaibh.sxruagbsvyjcprdxrmbbnanwlkitgksqkabzrztlblfbrtztytipqybqlzjmrou.vpovlkqbvrkkjdxrbqisagqoylptyisamqupxzlravlhbeviyypsckxfgusgp.], indique la racine de la hiérarchie DNS mais est souvent inutile pour la plupart des raisons pratiques. La transformation supprime le point, laissant [flbydawyqbxacdhfiknlpwwdxaswuxuraioxskrbzvijszsijbldlygxcnvcrze.lgrxgpunojzrftspdquunnuzdspfgeifkipjmjeueiysysgsuufzklxowenaibh.sxruagbsvyjcprdxrmbbnanwlkitgksqkabzrztlblfbrtztytipqybqlzjmrou.vpovlkqbvrkkjdxrbqisagqoylptyisamqupxzlravlhbeviyypsckxfgusgp], et vérifie que la longueur du domaine reste inférieure à 253 caractères. Cela garantit que le domaine reste utilisable tout en respectant les limites de longueur requises par le DNSDécomposition de l'IDNA
Les noms de domaine internationalisés (IDN) autorisent l'utilisation de caractères non ASCII, tels que des lettres accentuées ou des caractères d'alphabets non latins. Les systèmes DNS ne prenant en charge que les caractères ASCII, les IDN doivent être convertis en Punycode, une représentation ASCII normalisée. Cette transformation garantit que les domaines restent valides tout en étant compatibles avec la résolution DNS. Par exemple, le domaine [
société.com] (qui inclut le caractère « é ») est transformé en [xn--socit-esab.com]. Ce processus garantit que le domaine peut être traité par les serveurs DNS tout en conservant sa signification et son intention d'origine, ce qui permet de gérer efficacement les domaines multilingues.Suppression des crochets dans les adresses IPv6
Les adresses IPv6 sont parfois placées entre crochets, par exemple
[2001:db8::1], pour les différencier des noms de domaine classiques dans des contextes tels que les URL. Bien que les crochets soient utiles dans certains contextes, ils ne sont pas nécessaires pour le traitement DNS. Cette transformation supprime les crochets, laissant2001:db8::1. Ce faisant, le système garantit la cohérence du formatage des adresses IPv6 et prépare l'entrée pour un traitement ou une résolution ultérieurs.Suppression du point final du domaine
Les noms de domaine complets (FQDN) incluent parfois un point final pour indiquer explicitement la racine du DNS. Par exemple, [
www.olfeo.com.] inclut un point final. Bien que techniquement valide, le point n'est pas nécessaire dans la plupart des cas d'utilisation. Cette transformation le supprime, ce qui entraîne [www.olfeo.com]. La suppression simplifie la gestion des domaines et garantit un format cohérent dans l'ensemble du système tout en préservant la signification du domaine.Extraction de l'hôte si l'URL est fournie
Lorsqu'une URL complète ou une représentation d'hôte préfixée est fournie, cette transformation extrait la partie hôte, qui est le nom de domaine lui-même. Par exemple, à partir de l'entrée [
https://olfeo.com/path?query=123], le système extrait [olfeo.com], en supprimant le protocole (https://), chemin (/path) et une chaîne de requête (?query=123). Cette étape est importante pour les scénarios dans lesquels seul le nom de domaine est nécessaire, par exemple pour les recherches DNS ou les opérations spécifiques à l'hôteConcaténation d'URL
Cette transformation combine différentes parties d'une URL, telles que le chemin de base, les segments supplémentaires et les paramètres de requête, en une URL complète et fonctionnelle. Par exemple, si le domaine se termine par «
/foo» avec et une autre partie ajoute «/bar», le système les combine en «/foobar» pour créer un chemin unique et cohérent. Cela garantit que les URL sont correctement construites pour être utilisées dans les requêtes HTTP, les appels d'API ou les redirections, réduisant ainsi le risque d'erreurs provenant d'URL mal forméesAjouter un "/" au début de l'URL s'il manque
To standardize paths, this transformation ensures that a leading slash is added to URLs that lack one. For example, if the input URL is, [
olfeo.com], url: 'foobar', it is transformed into [olfeo.com], url: '/foobar'. Adding a leading slash makes the path consistent with URL formatting conventions and prevents errors caused by missing slashes during concatenation or routing operations.