在推特上抱怨面试时问HTTP GETE和POST的区别得到回答都不满意,有人不清楚,当时只回复了看 RFC2616。趁有空说说

面试时得到的回答大多是:POST是安全的,因为被提交的数据看不到,或者被加密的,其它的还有GET的时候中文出现乱码(在地址栏里),数据最大长度限制等等。

说 POST 比 GET 安全肯定是错的,POST跟GET都是明文传输,用httpfox等插件,或者像WireShark 等类似工具就能观察到。

POST和GET的差别其实是很大的。语义上,GET是获取指定URL上的资源,是读操作,重要的一点是不论对某个资源GET多少次,它的状态是不会改变的,在这个意义上,我们说GET是安全的(不是被密码学或者数据保护意义上的安全)。因为GET是安全的,所以GET返回的内容可以被浏览器,Cache服务器缓存起来(其中还有很多细节,但不影响这里的讨论)。

而POST的语意是对指定资源“追加/添加”数据,所以是不安全的,每次提交的POST,参与的代码都会认为这个操作会修改操作对象资源的状态,于是,浏览器在你按下F5的时候会跳出确认框,缓存服务器不会缓存POST请求返回内容。

很遗憾到目前为止没有应聘者能够提到这一点。我猜测这背后的原因大概有两个,一是也许大多数人往往(我也一样)满足于只要完成任务就好,不管用哪个,表单提交了,数据处理了,内容显示或者重新定向到另外一个页面,就算完成了一个任务,从任务表里划掉,结束。而且对大部分项目(OA, CRM, MIS)的大部分情况下,用哪个似乎都可以。

同时,在被商业机构在媒体和书籍上宣传兜售的WS-*概念和使用集成开发环境提供的“方便”的代码生成工具后,“了解”到所有Web服务调用都是通过POST,更潜意识里确定了POST和GET是一样的,而且GET能做的,POST都能做,POST简直就是GET++嘛。自然,能用POST就用POST,不必在乎两者的差别了。

这又让我想起最近学到的一个概念: Radius Of Comprehension,理解的半径:

当学习概念A的时候,需要先了解概念B,而概念C又是理解B的前提。当B和C都是新的需要学习的概念时,可以说A的理解半径是2,如图:

A --> B --> C
|--1--|--2--|

在学习Web开发时,接触到GET和POST时,“理解的半径”可能包涵:

POST vs. GET
     |---> Conditional GET -> ETag -> Cache
     |         `--> Status Code
     `---> HTTP的方法 --> URL

往往因为仅仅满足于完成手上被要求的任务,或者懒于问一个为什么,我们就把自己的理解半径设置成零,那么就学不到更深入的东西,也因此仅仅知道POST和GET不同,而不再会了解不同在哪里,什么是Conditional GET和缓存header等概念。

从一个简单的面试问题谈到这,貌似小题大作了,写到哪算哪吧。

<UPDATE>
看到Fenng Buzz 了这篇文字,引起一些评论,因此在这再讨论两个概念: 安全的(Safe)和幂等的(Idempotent)

安全的是指没有明显的对用户有影响的副作用(包括修改该资源的状态)。HTTP方法里的GET和HEAD都是安全的。

幂等的是指一个方法不论多少次操作,结果都是一样。PUT(把内容放到指定URL),DELETE(删除某个URL代表的资源),虽然都修改了资源内容,但多次操作,结果是相同的,因此和HEAD,GET一样都是幂等的。

所以根据HTTP协议,GET是安全的,也是幂等的,而POST既不是安全的,也不是幂等的。
</UPDATE>

I have enjoyed paper/white-board prototyping for a long time, even made it my teams’ one of first “rules of engagement”. I have also been a big fan of Balsamiq Mockups, and today I would like to introduce you another great quick prototyping tool: WireframeSketcher.

In a nutshell, WireframeSketcher is, as its home page says:

WireframeSketcher is an Eclipse plugin for creating wireframes, screen mockups and UI prototypes.

Having tried it out on two small projects in the last two weeks, I am impressed. It’s a neat, and pleasant tool to use and fits very well with both my personal and my team’s development process.

First, a screen-shot showing it in action:

wireframesketcher-screenshot

Being an Eclipse plugin, it means

  • developer friendly, as it’s right inside an environment already familiar to many developers (80% of my team uses eclipse on a daily basis), there is no extra software or framework or platform to install, and developers can just svn up project’s design mockup folder, then open the mockups in the same IDE, very neat and appealing experience compared to that of other prototype tools;
  • cross platform;
  • enjoys the benefits Eclipse plugin infrastructure brings, like update mechanism

Highlights I want to mention:

  • The fastest and most responsive prototype tool I have tried and used;
  • Mockups are stored as xml documents instead of image files, that means it’s friendly to scm tools like Subversion and diff;
  • Has annotation support, good for asynchronous communication;
  • Grouping of UI elements can be nested, i.e. I can group a label and an input box first, then group them with a button as another group, when ungrouping the latter, the first group of label and input box is still intact;
  • Presentation of a mockup or a storyboard is handy, it’s right inside Eclipse. There is no need to export them to images first then pasted to a .ppt file in order to just show the mockups or the sequence of the mockups;

The most pleasant surprise to me is “Master Screen”, which allows me to pick any existing mockup as the base of a new mockup, this helps save time particularly when many of a site pages share the same header and footer. And there’s more. When I later make changes to the master screen, all screens that are “derived” from it automatically get updated without their xml files being modified (again, very friendly to Subversion and the like).

A close look of my sample mockups:

wireframesketcher-1

Storyboard example:

wireframesketcher-storyboard

Some nitpicks or features I would like to see in the future WireframeSketcher:

  • annotation does not provide link from notes to the annotated element
  • I strongly believe url is an important element of user experience, but currently there is no way to specify the url on the browser control (I would suggest it takes two lines of input, the first being the page title, and the second line for the url);
  • I couldn’t find a way to reuse a group of UI element, my idea is to allow user to have a collection of custom built (e.g. Paginator, Chinese version of “Loren Lpsum”) or assembled controls or control groups (e.g. a text input field always comes with a label and input box) as a separate category, this would help productivity among a project team at least;
  • colors support in more controls (e.g. form validation error, and different colors in progress bar, red for slow progressed, and green for complete or near complete)
  • One feature I particularly like about Balsamiq Mockups is the command line script to batch process (e.g. export to image files), I use it in my Ant build script to export mockup images. I hope this feature is coming to WireframeSketcher soon;
  • Hopefully, a community could grow out of this tool, like what Balsamiq has achieved with Mockups To Go;

Conclusion? I would strongly encourage any developer or any development team that live and breathe in Eclipse to give WireframeSketcher a serious try.

Oh, did I mention a tiny problem with it being an eclipse plugin? RescueTime now can not tell if I am actually using a Dev Tool or a Design Tool … But heck, I sure can live with that given such a great prototype tool.

平时工作中在界面设计的时候,我总是要求工程师先在纸上画图,初步确定后,仅仅用HTML+CSS做出静态的界面再次与用户(主要是其他业务部门)确认后,再动手写实际的代码。

纸上的原型设计是经常使用(至少我自己)的初期设计方式,办公室里用白板(空间大,而且环保些)和马克笔。这种办法不仅快,能尽早发现在文字和口头的沟通上理解不一致的地方,同时也尽可能减少开发成本和因为理解不一致导致返工的情况。纸上的原型设计在可用性上能起到很大作用,也有专门一本书介绍和探讨,这就不多说了。

但是这也有它们本身的不足。首先是没法很好地保留设计和讨论的内容,我曾经尝试用数码相机把白板上的内容拍下来,但仅仅是为了保留,没法有效地在后续的讨论和工作中继续使用。

几年前发现过一个做网站的设计草图的工具软件,Denim,这是一个大学的项目,学术性和尝试性的味道强了些,界面设计上有很多新颖的地方,但毕竟不是从每天蹲在“战壕”中的工程师的角度出发,玩玩可以,实际工作上还是不大可能用上。(附:Denim的截图)。

前阵子发现了一个新软件:Balsamiq Mockups,用下来发现它真正抓住了原型设计的核心与平衡点,既能快速设计草图,又能比较好地进入到平时团队工作的流程和工具中,可以说是击中了原型设计的Sweet Spot,强烈推荐。

先看看截图:
balsamiq markup screenshot

再说说功能和亮点:

  1. 操作方面,拖拽,控件分组,甚至元素之间的对齐都做得很贴心;
  2. 预制了很多界面元素,从简单的输入框,下拉框,浏览器主要元素,到经常用得到的导航条,日历,表格,到复杂的Tag Cloud,Cover Flow, 地图,WYSWYG的格式工具栏等,有了这些不用从头画起,往往比用白板都快;
  3. 界面元素的修改很简单,比如导航条的几个标签页的label,就是用逗号分隔的文字,下拉框的选项就是分行的文字;
  4. 使用xml语言来记录和保存界面元素和布局,
    1. 这使得每个设计都能被很好得放进SVN,Git,和CVS等工具中进行管理和跟踪;
    2. 可以设计复杂的界面元素,保存后,以后可以重复使用(包括修改);
  5. 可以将设计导出成PNG格式的图片;
    balsamiq markup exported to png
  6. 可以用命令行进行导出操作,这样就能让我写个脚本,从svn里checkout某个目录下的所有设计文件后,导出图片,打包后用邮件发到项目经理,工程师甚至客户那;
  7. 跨平台,Balsamiq Mokups是用Flex和Air实现的,所以在Mac OS, Linux和Windows下都能使用;
  8. 不仅仅有桌面版本,还有能集成在Confluence,JIRA,和XWiki中的版本,使得异地在线协作更方便有效;

据作者说,现在这款软件的设计就是用它自己来设计的,经典的“吃自己的狗粮”,这也让我对其更有信心,因为它是开发者为开发者写的软件

更多信息,大家可以到它的网站上了解。

还有值得一提的是Balsamiq Mokups的在GetSatisfaction上的用户支持和服务,作者Peldi对问题报告,新需求的回应很积极和及时。而且根据这个讨论上看,到月底就会有一个专门用来分享界面控件设计的社区网站了,很期待。

再要说的一点是这款软件是要付费的,79美元(也可以免费,具体如何免费,请看网站上的说明),相对于它能节省下来的时间和提高的效率,是很值得的。Peldi说在2008年,这款软件就从1,322位付费用户那获得了162,302美元的收入(其中仅12月份就有39,000美元),这令人鼓舞地证明了只要是提供真正价值的服务和软件,就能够创造很好的收入,即使在经济萧条的寒冬里。

另外说一句, GetSatisfaction也是一个很不错的服务。

cnbloggercon, Web, WebDev @ 16 November 2007, “1 Comment”

在Firefox上安装了支持微格式(Microformats)的扩展(Operator, Tail Export等)的,也许会注意到年会注册程序的页面上已经提供了hCalendar的支持。以下是在这些页面上使用几个扩展的截图。

下面是Tail Export在边栏里列出的年会议程页面页面上所有hCalender微格式,用户可以点击export图标把感兴趣的活动/议题加入到本地的程序比如Outlook, Mozilla Calendar项目的软件比如Thunderbird Lightning等。

cbc-uf-tail-export-uf-list

导入到Outlook里后:

outlook-2a

我个人更喜欢Operator这个扩展,因为它还能把微格式导入到在线的日历服务比如Google Calendar和Yahoo! Calendar,而且似乎对unicode支持比较好。以下是截图:

cbc-uf-operator-menu-options

导入到GCal里:

cbc-uf-operator-export-to-gcal

链接:更多关于微格式的截图

从这些页面和本地程序的数据交互,以及网页和网页之间的程序调用和数据交互,展示了语义网(Semantic Web),最基础的技术支持(HTML, MIME, HTTP)就能提供很好的在线和本地(尤其是移动终端, iphone, mobile firefox? mobile xulrunner?)集成以及更好的用户体验。

另:年会注册程序里除了hCalendar,年会页面当然也能提供hCard(个人信息)的微格式,但是在没有更好的隐私保护措施和共识之前,对hCard的支持目前还是没有开放出来。其它的格式比如FOAF,hReview,rel-tag, rel-license等的支持,会在将来陆续提供。

P.S. 有点遗憾,因为临时有事,没能来得及在年会开始之前做这个介绍。

WebDev @ 29 August 2007, “6 Comments”

减少DNS查找能够缩短页面反应时间,但是所有网站资源都只用一个域名,从而把DNS查找减少到一个,也不是最好的办法。不仅仅因为减少的平行下载的可能,更因为Web Cache对带与不带cookie的请求和返回的处理不同。

我的网站域名是www.yining.org,有个页面(比如就这篇blog entry)带有一张图片,其src为:/img/camel.gif,那么它的URL就是:”http://www.yining.org/img/camel.gif”。如果这个页面设置了cookie(比如为了记录留言者的ID和网站地址等),cookie的作用域名自动为www.yining.org,那么每次访问该页的时候,因为URL的域名部是www.yining.org,那么浏览器都会带着cookie对该图片发起请求,即使一路上的web cache有www.yining.org/img/camel.gif的记录,也依然要到我的服务器(the origin server),而不是从中间的web cache返回 – 因为带cookie的请求都可能根据不同cookie的值而返回不同的response。

但是这对许多静态资源(图片, css, 和javascript)来说不是最理想的,因为不论cookie是什么,它们的response里都是同样的内容,对它们的请求没有必要每次都回到origin server。其次,因为不同web cache对带cookie的请求支持不同,即使有的cache能够缓存带cookie的response,但是1)不是大多数的cache都能做到这点,2)大多数的cache都缺省缓存不带cookie的response。因此最好的办法就是使用不同的域名把静态资源隔离开。虽然cookie的path属性也能做到这点,但是毕竟限制太多,不如使用专门的域名灵活。

所以应该尽量把所有静态的对象和动态页面的域名分开,更严谨地说,是把不需要读写客户端cookie的服务器资源与需要读写cookie的程序分开到不同的域名。比如我可以设置另一个域名static.yining.org,在引用该图片的<img>里的src属性改为”http://static.yining.org/img/camel.gif”,那么当访问首页的时候,浏览器就不会带着cookie(因为作用的域名现在不一样了),这样就能更好地利用web cache缓存和服务器的性能。我请教过一位曾经在NetAppliance(最大的web cache厂商)工作的同学,据他说根据经验,带和不带cookie之间的差别有可能是20%甚至更大。

WebDev @ 01 August 2007, “1 Comment”

雅虎的YSlow插件的规则之一:Rule 9 – Reduce DNS Lookups提到:

Reducing the number of unique hostnames has the potential to reduce the amount of parallel downloading that takes place in the page. Avoiding DNS lookups cuts response times, but reducing parallel downloads may increase response times. My guideline is to split these components across at least two but no more than four hostnames. This results in a good compromise between reducing DNS lookups and allowing a high degree of parallel downloads.

说说自己的理解:

首先,一个页面所需要访问的域名数量为n,那么就需要n次DNS查找,而DNS查找通常是blocking call,就是说在得到结果之后才能继续,所以越多的DNS查找,反应速度就越慢;

其次,并行下载(parallel downloading)由两个因素决定:到服务器的连接数量,以及每个连接内部的流水线请求数量。

一个页面里到服务器的连接数量由两个因素决定:

  1. 页面所需访问的域名数量,和
  2. 浏览器所允许的最多连接数

后者在Mozilla/Firefox中还由浏览器所允许最多连接数(network.http.max-connections,缺省为24),和每个服务器所允许的最大连接数(network.http.max-connections-per-server,缺省为8)决定。如果max-connection-per-server是m,那么一个需要访问n个不同域名的主机的页面,最多可以有n*m个连接 - 前提是n*m小于max-connections的值;

每个连接内部的流水线请求(pipelined requests)的数量也是浏览器的参数(Firefox上由network.http.pipelining来设置,缺省为4),前提是服务器支持persistent connection(比如在Apache设置KeepAlive为On)。之前的例子就不需要那么多的连接了(对服务器和浏览器来说,一个连接里多个流水线请求能够比多个并行连接更好些),假设pipelining的值为p,那么就可以只使用n*m/p个连接了。(BTW,对Firefox做优化的一些插件其实就是对上面的几个设置做调整)

所以减少页面内不同hostname的数量不一定会减少并行下载的数量,也要看所需要的请求(css, javascript, 图片等)的数量,因此YSlow的解释说是potentially。

WebDev @ 26 July 2007, “2 Comments”

雅虎今天推出了YSlow插件(这名字不错:Why Slow? ),需要先装Firebug,YSlow其实是它的“插件”。YSlow从Firebug收集当前网页和该网页的访问信息后进行分析,如有必要则给出如何提高页面加载速度的建议,比如减少DNS查询,使用外部并压缩Javascript等。这些建议是根据13个提高网页速度的指导原则,其内容已经在Yahoo Developer Blog上系列连载了一段时间,最近更新速度快了很多几乎每天一篇(是为了配合YSlow的推出?)。除此外还有专门一本书:《High Performance Web Sites》,内容就是这个系列(多了一个关于Ajax的专题),应该有更深入的分析和解释(这本书是Rough Cut,所以有O’Reilly Safari帐号的可以先睹为快了)。

这个High Performance系列说明网站开发者(包括我自己)非常需要深入了解HTTP和HTML。对Java尤其尤其是J2EE程序员来说,不要只是build around the web, 而是build for the web。很多程序员(尤其是刚毕业的大学生)不在意HTTP的细节,从所谓的“企业级开发”的角度把HTTP请求仅仅当作作一种函数调用,导致能提高性能的所有HTTP的特性都被“抽象”掉了,也就不了解或者利用这些属性。比如,我常在面试的时候问:HTTP GET和POST的区别在哪里?大部分的回答只有参数大小和位置的不同。

YSlow上的指导原则里的内容还有些可以补充的(很多东西应该都放到那本书里去了吧),比如在High Performance Web Sites: Rule 13 – Configure ETags里,作者建议在Apache上把ETag关掉,实际上只需要告诉Apache不要用Inode信息生成ETag就可以。还有其他一些,回头写上来。这里这里,和这里也有很多非常好的建议。

另外要注意的是,网页速度跟网站性能是不同的概念,网页在浏览器上加载得快,并不能保证网站的性能就好,虽然二者之间有密切的关联。

P.S. 关于网站的延展性(scalability)和速度(performance),O’Reilly已经出了两本,另一本是《Building Scalable Web Sites》,都是雅虎员工写的,在这要赞一下雅虎对Web开发社区的贡献。