java.net.http非HTTP(S)URI请求示例及URI优于URL的原因

1. 是否存在非HTTP(S)协议的可用请求URI示例？ #

明确说明：java.net.http.HttpClient仅支持HTTP/HTTPS协议的请求，非HTTP(S)的URI（如ftp://example.com/file.txt、file:///local/path、ws://example.com/ws）虽然语法上可以传入HttpRequest.newBuilder()，但执行请求时会抛出异常。

示例代码（执行时会报错）：

HttpRequest request = HttpRequest.newBuilder()
    .uri(new URI("ftp://ftp.example.com/pub/file.txt"))
    .GET()
    .build();

// 执行请求时会抛出：java.net.ProtocolException: Expected HTTP scheme

这是因为HttpClient的设计目标就是处理HTTP/HTTPS通信，不支持其他协议的请求处理逻辑。

2. 为什么HttpRequest构建器选用URI而非URL？ #

Java中URI和URL的核心差异，决定了URI更适合这个场景：

核心区别 #

• URL是资源定位符，不仅标识资源，还包含获取资源的协议与位置，创建时会尝试解析主机名（涉及DNS查询），可能导致阻塞或性能问题。
• URI是资源标识符，仅做字符串层面的语法校验，不涉及任何网络操作，更轻量、安全，还能支持相对路径等灵活的标识形式。

URI的优势示例 #

示例1：避免不必要的网络依赖

创建URL时会触发DNS解析，而URI仅做语法校验，无阻塞风险：

// 创建URL可能因DNS解析失败/缓慢抛出异常，且阻塞线程
try {
    URL url = new URL("https://example.com");
} catch (MalformedURLException e) {
    e.printStackTrace();
}

// 创建URI仅校验字符串格式，不涉及网络
try {
    URI uri = new URI("https://example.com");
} catch (URISyntaxException e) {
    e.printStackTrace();
}

示例2：便捷的相对URI拼接

URI原生支持基于基地址的相对路径拼接，适合构建API请求：

// 基地址URI
URI baseUri = URI.create("https://api.example.com/v1/");
// 相对路径
String relativePath = "users/123";

// 直接拼接得到完整请求URI
URI fullUri = baseUri.resolve(relativePath);
// 结果：https://api.example.com/v1/users/123

HttpRequest request = HttpRequest.newBuilder(fullUri)
    .GET()
    .build();

如果用URL实现类似逻辑，需要手动拼接字符串或借助复杂的连接操作，远不如URI简洁可靠。

示例3：更稳定的equals/hashCode实现

URL的equals()方法会解析主机IP进行比较，相同域名不同IP（如CDN场景）会被判定为不相等；而URI仅做字符串语法层面的比较，结果可预测，适合作为缓存键或集合元素。

内容的提问来源于stack exchange，提问作者Michiel Borkent