Spring的 Resource 接口是为了提供更强的访问底层资源能力的抽象。
public interface InputStreamSource {
boolean exists();
boolean isOpen();
URL getURL() throws IOException;
File getFile() throws IOException;
Resource createRelative(String relativePath) throws IOException;
String getFilename();
String getDescription();
}
public interface InputStreamSource {
InputStream getInputStream() throws IOException;
}
Resource 接口一些比较重要的方法如下：
getInputStream(): 定位并打开资源，返回读取此资源的一个InputStream。每次调用预期会返回一个新的InputStream，由调用者负责关闭这个流。exists(): 返回标识这个资源在物理上是否的确存在的boolean值。isOpen(): 返回标识这个资源是否有已打开流的处理类的boolean值。如果为true，则此InputStream就不能被多次读取， 而且只能被读取一次然后关闭以避免资源泄漏。除了InputStreamResource，常见的resource实现都会返回false。getDescription(): 返回资源的描述，一般在与此资源相关的错误输出时使用。此描述通常是完整的文件名或实际的URL地址。
其它方法让你获得表示该资源的实际的 URL 或 File 对象(如果隐含的实现支持该方法并保持一致的话)。
Spring自身处理资源请求的多种方法声明中将Resource 抽象作为参数而广泛地使用。
Spring APIs中的一些其它方法(比如许多ApplicationContext的实现构造函数)，使用普通格式的 String 来创建与context相符的Resource，也可以使用特殊的路径String前缀来让调用者指定创建和使用特定的 Resource 实现。
Resource不仅被Spring自身大量地使用，它也非常适合在你自己的代码中独立作为辅助类使用。
用户代码甚至可以在不用关心Spring其它部分的情况下访问资源。这样的确会造成代码与Spring之间的耦合，但也仅仅是与很少量的辅助类耦合。这些类可以作为比 URL 更有效的替代，而且与为这个目的而使用其它类库基本相似。
需要注意的是 Resource 抽象并没有改变功能：它尽量使用封装。
比如 UrlResource 封装了URL，然后使用被封装的 URL 来工作。