目录:

HTML总是以链接地址的方式引入图片,尽管我们能在网页内嵌入以BASE64编码后的图片字符,但终究网页不是Word,传输方式决定了一个表意完善,可供用户选择性显示的HTML文本,要好过夹杂了臃肿不堪的媒体文件代码的文档。

但是传统的图片外置方式,带来了很多附加的问题

  1. 服务器地址经常变动,容易过期
  2. 如果采用缩略图,则必然产生一个新的与原图无关的URL,带来大量的冗余
  3. 包含信息量不足,目前图片的所有附加信息(时间,拍摄地点,描述,分类等等)仅仅使用alt属性来对图片进行简单描述,远远不足以应对Web2.0网状的Tag关联描述

好在一切有了REST!

REST构架下的互联网是那样美好,所有的资源都有唯一的,表意良好的资源定位,无需再为页面间无意义的跳转发愁,资源检索的设计空前简单……

但这一切在现有的B/S模式基础上实现的话,代价是极为高昂的。现有的浏览器无法根据用户对单一超链接的点击判断用户的动作究竟是要访问,更新还是删除。同样的,服务器端也只能使用程序本身的入口来分析Header并判断用户究竟要干什么,而不是自动的将不同的Header请求分发到对应接口。

所以一个简单的REST构架实现,在现有的设备中,或者说在我的这个简单实现中,至少需要一个将超链接转换为客户端请求的分析器(AJAX),一个服务器端的请求分析器(PHP),一个将针对各种请求的转发器(PHP+Picasa API)。

而更重要的实现REST构架之前,我们需要做的不仅仅是考虑能不能实现,更需要权衡构架实现所需花销与实现后带来收益是否相符。

那么是否相符呢?还是用最终的结果来说话吧。

点击查看DEMO

Demo中实际的HTML代码只有一行

<img class="photo" src="photo/picasa/allovince/5213571636180988625/5213571644436936978"/>

和普通的图片引入没有任何区别,但最终我们可以在页面上看到这张照片的标题、拍摄时间、原图等等附加信息,当然本Blog也是通过这种方法进一步扩展,搭配了华丽的Lightbox特效等等,有兴趣的同学可以自行翻看。

总之抛去最后的结果不谈,这个REST构架应用的最终结果就是,用户一切所要做的,只是提供上面这样的一行代码,而获得额外的相关信息以及丰富的扩展应用。


 Tags : YD的程序员葛阁 REST

Donate:Buy me a coffee  | 文章有帮助,可以请我喝杯咖啡