URI deep link per app mobile

ref=email. I team di prodotto, growth e engineering necessitano che tali URI deep link siano sempre ben formate: un token di scheme legale, host e path prevedibili e coppie di query percent-encoded che sopravvivano al copia-incolla in payload push, SMS, codici QR e destinazioni pubblicitarie. Questa capacità accetta uno scheme personalizzato, host opzionale, path opzionale e un elenco opzionale di coppie chiave/valore di query, valida lo scheme rispetto alla produzione RFC 3986, normalizza il path, codifica la query e restituisce la stringa deep_link finita più campi di eco strutturati. I caratteri di scheme non validi falliscono con invalid_input invece di emettere in silenzio una URI rotta.

Cos'è un deep link con scheme personalizzato e come si assembla l'URI

Un deep link mobile con scheme personalizzato è un'URI che il sistema operativo instrada verso la Sua app installata anziché verso il browser. Lo scheme è il token prima dei due punti e della doppia barra—myapp, com.example.app o my-app+v2—e deve seguire la grammatica degli scheme URI: prima una lettera, poi solo lettere, cifre, più, punto o trattino. Spazi, underscore, due punti e slash all'interno dello scheme sono illegali e sono gli errori di copia-incolla più comuni quando un nome di prodotto viene usato come scheme senza sanificazione. Chiavi e valori di query sono percent-encoded con le stesse regole usate dai browser per componenti in stile application/x-www-form-urlencoded, così gli spazi diventano escape stile %20 e i caratteri riservati non possono spezzare la query. Dopo scheme:// arriva un host opzionale (a volte detto authority), come product, open o auth, poi un path opzionale come /item/42, quindi una stringa di query opzionale di coppie chiave uguale valore unite da ampersand. Questo costruttore concatena tali pezzi in un ordine fisso: scheme, letterale ://, host (può essere vuoto), un path che riceve sempre una singola slash iniziale se non vuoto, e una stringa di query solo quando è presente almeno un parametro. Quando l'host è vuoto e il path è /promo, il risultato appare come myapp:///promo; quando host e path sono entrambi vuoti ottiene comunque un guscio legale scheme:// utile come intent bare di apertura app. La risposta echeggia scheme, host, path, query_params, query_string, deep_link e has_query così i client possono registrare parti strutturate senza riparsare l'URI. Poiché l'algoritmo è puro e deterministico, gli stessi input producono sempre lo stesso deep_link byte per byte sul percorso gratuito del browser e sul percorso API a pagamento.

Contratto di input, regole di validazione e comportamento degli errori

Sono accettate al massimo cinquanta coppie. Invii in POST un corpo JSON con scheme come unico campo strettamente obbligatorio: una stringa non vuota dopo il trim che corrisponde al pattern lettera poi lettere, cifre, più, punto o trattino. Sono accettati gli alias url_scheme, custom_scheme e protocol. host è opzionale e di default è la stringa vuota; se impostato non deve contenere spazi, slash, punto interrogativo o cancelletto. path è opzionale; se non vuoto non deve contenere spazi, punto interrogativo o cancelletto, e viene inserita una slash iniziale se Lei la omette, così item/42 diventa /item/42. query_params è un array opzionale di oggetti, ciascuno con key obbligatoria e value opzionale (default stringa vuota); gli alias query, params e search_params funzionano allo stesso modo. Ogni key deve essere non vuota dopo il trim; i valori possono essere stringhe, numeri o booleani e vengono convertiti in stringa prima della codifica. scheme assente o vuoto, scheme con caratteri non validi, caratteri illegali in host o path, query_params non array o key vuote falliscono con invalid_input e un messaggio chiaro che nomina il problema—tali fallimenti non vengono fatturati. In caso di successo riceve scheme, host e path normalizzati; l'elenco query_params normalizzato; query_string senza punto interrogativo iniziale; deep_link come URI completa; e has_query come booleano. Esempio: scheme myapp, host product, path /item/42 e query_params ref uguale a email più utm_source uguale a newsletter produce myapp://product/item/42? ref=email&utm_source=newsletter. Abbini deep_link ai domini associati o agli intent filter della Sua app sul client; questo endpoint costruisce solo la stringa URI e non registra gli scheme con il SO né verifica che l'app sia installata.

Dove un costruttore di URI deep link ripaga l'investimento

I backend di notifiche push compongono scheme, host di schermata e id entità in un unico campo deep_link che il client mobile può analizzare al cold start. Le app white-label multi-tenant mappano ogni brand al proprio token di scheme e condividono comunque un costruttore per le convenzioni di path e query. Poiché l'implementazione è parse puro tier A, ogni chiamata riuscita costa il prezzo base pubblicato $0.002 senza token di modello e senza rete in uscita.