Io sono retro-fitting un'applicazione di fare uso di un proxy PHP HTTP (per il caching) invece del server API attuale, l'applicazione attualmente unisce il server URI e il percorso con il codice:Combinando URI e percorsi
methodUri = new Uri(apiUri, method.Path)
Dove:
- apiUri = "http://api.eve-online.com/" (System.Uri Object)
- method.Path = "/ car/Sk illIntraining.xml.aspx"(stringa)
Il risultato della dichiarazione di cui sopra è
"http://api.eve-online.com/char/SkillIntraining.xml.aspx" (System.Uri Object)
Per utilizzare il proxy HTTP PHP la richiesta deve essere cambiato come segue
- apiUri = "http://www.r-s.co.uk/eproxy.php" (Oggetto System.Uri)
- method.Path = "/char/SkillIntraining.xml.aspx" (stringa)
L'uscita mi aspettavo era:
"http://www.r-s.co.uk/eproxy.php/char/SkillIntraining.xml.aspx" (System.Uri Object)
Tuttavia l'output che ottengo è:
"http://www.r-s.co.uk/char/SkillIntraining.xml.aspx" (System.Uri Object)
I Capisco che questa è la funzionalità corretta del costruttore Uri (Uri, stringa), la mia domanda è quale sarebbe una funzione o costruttore migliore da utilizzare al suo posto per ottenere l'output che mi aspetto? Ho provato a rimuovere il principale "/" in method.Path portarlo da un percorso assoluto a un percorso relativo che tuttavia non ha aiutato.
NOTA: entrambe le soluzioni di seguito funzionano, tuttavia System.UriBuilder fornisce un meccanismo più robusto per combinare URI e percorsi e nel mio caso portato a un minor numero di modifiche alle risorse rispetto all'utilizzo System.Uri. Se avessi la scelta, segnerei entrambe le risposte come corrette.
Sei corretto System.UriBuilder è un modo più robusto per costruire URI, grazie –
Nota che il percorso sarà codificato come URL, quindi se l'aggiunta contiene una stringa di interrogazione i caratteri? e & saranno codificati. una debolezza in questo metodo come descritto: –
'UriBuilder' ha una proprietà Query separata per le stringhe di query, che è raccomandata man mano che gestisce la codifica dei caratteri per quel caso d'uso –