Je me suis certainement retrouvé à faire plus d'une fois le même code de manipulation d'URI, en .NET, mais je ne vois pas dans vos cas des endroits où cela fait défaut.
URI complet à partir de l'Uri relatif :
new Uri(base, relative) // (works whether relative is a string or a Uri).
Obtention du FQDN réel :
string host = uri.Host;
string fqdn = hostEndsWith(".") ? host : host + ".";
Forcer https ou revenir à http :
UriBuilder toHttp = new UriBuilder(someUri);
toHttp.Scheme = "http";
toHttp.Port = 80;
return toHttp.Uri;
UriBuilder toHttps = new UriBuilder(someUri);
toHttps.Scheme = "https";
toHttps.Port = 443;
return toHttps.Uri;
Obtenir la racine du site :
new Uri(startingUri, "/");
Combiner correctement les urls relatives :
new Uri(baseUri, relUri); // We had this one already.
Seuls deux d'entre eux sont plus qu'un simple appel de méthode, et parmi ceux-ci, l'obtention du FQDN est plutôt obscure (à moins que, au lieu de vouloir le FQDN à points, vous vouliez simplement l'URI absolu, auquel cas nous en revenons à un simple appel de méthode).
Il existe une version à méthode unique de la commutation HTTPS/HTTP, bien qu'elle soit en fait plus lourde puisqu'elle appelle plusieurs propriétés de l'objet Uri. Je peux vivre avec le fait que cela prenne quelques lignes pour faire ce changement.
Pourtant, pour fournir une nouvelle API, il suffit de la fournir :
public static Uri SetHttpPrivacy(this Uri uri, bool privacy)
{
UriBuilder ub = new UriBuilder(uri);
if(privacy)
{
ub.Scheme = "https";
ub.Port = 443;
}
else
{
ub.Scheme = "http";
ub.Port = 80;
}
return ub.Uri;
}
Je ne vois vraiment pas comment une API pourrait être plus concise dans les autres cas.