URI deep link app mobile

ref=email. Les équipes produit, growth et ingénierie ont besoin que ces URI de deep link soient bien formées à chaque fois : un jeton de scheme légal, un host et un path prévisibles, et des paires de requête percent-encoded qui survivent au copier-coller dans les payloads push, SMS, codes QR et destinations publicitaires. Cette capacité accepte un scheme personnalisé, un host optionnel, un path optionnel et une liste optionnelle de paires clé/valeur de requête, valide le scheme contre la production RFC 3986, normalise le path, encode la query et renvoie la chaîne deep_link terminée plus des champs d'écho structurés. Les caractères de scheme invalides échouent avec invalid_input au lieu d'émettre une URI cassée en silence.

Qu'est-ce qu'un deep link à scheme personnalisé et comment l'URI est assemblée

Un deep link mobile à scheme personnalisé est une URI que le système d'exploitation achemine vers votre application installée plutôt que vers le navigateur. Le scheme est le jeton avant les deux-points et la double barre—myapp, com.example.app ou my-app+v2—et doit suivre la grammaire des schemes URI : une lettre d'abord, puis uniquement lettres, chiffres, plus, point ou tiret. Espaces, underscores, deux-points et barres à l'intérieur du scheme sont illégaux et constituent les erreurs de copier-coller les plus fréquentes lorsqu'un nom de produit sert de scheme sans assainissement. Les clés et valeurs de requête sont percent-encoded avec les mêmes règles que les navigateurs pour les composants style application/x-www-form-urlencoded, de sorte que les espaces deviennent des échappements style %20 et les caractères réservés ne peuvent pas scinder la query. Après scheme:// vient un host optionnel (parfois appelé authority), comme product, open ou auth, puis un path optionnel comme /item/42, puis une chaîne de requête optionnelle de paires clé égale valeur jointes par des esperluettes. Ce constructeur concatène ces pièces dans un ordre fixe : scheme, littéral ://, host (peut être vide), un path qui reçoit toujours une seule barre initiale lorsqu'il est non vide, et une chaîne de requête uniquement lorsqu'au moins un paramètre est présent. Lorsque le host est vide et le path est /promo, le résultat ressemble à myapp:///promo ; lorsque host et path sont vides, vous obtenez encore une coque légale scheme:// utile comme intent bare d'ouverture d'app. La réponse fait écho de scheme, host, path, query_params, query_string, deep_link et has_query afin que les clients journalisent des parties structurées sans reparser l'URI. Comme l'algorithme est pur et déterministe, les mêmes entrées produisent toujours le même deep_link octet pour octet sur le chemin gratuit du navigateur et sur le chemin API payant.

Contrat d'entrée, règles de validation et comportement d'erreur

Au plus cinquante paires sont acceptées. Envoyez en POST un corps JSON avec scheme comme seul champ strictement obligatoire : une chaîne non vide après trim qui correspond au motif lettre puis lettres, chiffres, plus, point ou tiret. Les alias url_scheme, custom_scheme et protocol sont acceptés. host est optionnel et vaut par défaut la chaîne vide ; lorsqu'il est fourni il ne doit pas contenir d'espaces, de barre, de point d'interrogation ni de dièse. path est optionnel ; lorsqu'il est non vide il ne doit pas contenir d'espaces, de point d'interrogation ni de dièse, et une barre initiale est insérée si vous l'omettez, de sorte que item/42 devient /item/42. query_params est un tableau optionnel d'objets, chacun avec une key obligatoire et une value optionnelle (défaut chaîne vide) ; les alias query, params et search_params fonctionnent de même. Chaque key doit être non vide après trim ; les valeurs peuvent être chaînes, nombres ou booléens et sont converties en chaîne avant encodage. scheme manquant ou vide, scheme avec caractères invalides, caractères illégaux dans host ou path, query_params non tableau ou keys vides échouent avec invalid_input et un message clair nommant le problème—ces échecs ne sont pas facturés. En cas de succès vous recevez scheme, host et path normalisés ; la liste query_params normalisée ; query_string sans point d'interrogation initial ; deep_link comme URI complète ; et has_query comme booléen. Exemple : scheme myapp, host product, path /item/42, et query_params ref égal email plus utm_source égal newsletter produit myapp://product/item/42? ref=email&utm_source=newsletter. Associez deep_link aux domaines associés ou intent filters de votre app côté client ; ce point de terminaison construit uniquement la chaîne URI et n'enregistre pas les schemes auprès de l'OS ni ne vérifie que l'app est installée.

Où un constructeur d'URI deep link prouve sa valeur

Les backends de notifications push composent scheme, host d'écran et id d'entité en un seul champ deep_link que le client mobile peut analyser au cold start. Les apps white-label multi-tenant associent chaque marque à son propre jeton de scheme et partagent encore un constructeur pour les conventions de path et de query. Comme l'implémentation est parse pur tier A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle et sans réseau sortant.