初探Java字符串

String印象

String是java中的无处不在的类,使用也很简单。初学java,就已经有字符串是不可变的盖棺定论,解释通常是:它是final的。

不过,String是有字面量这一说法的,这是其他类型所没有的特性(除原生类型)。另外,java中也有字符串常量池这个说法,用来存储字符串字面量,不是在堆上,而是在方法区里边存在的。

字面量和常量池初探

字符串对象内部是用字符数组存储的,那么看下面的例子:

String m = "hello,world";
String n = "hello,world";
String u = new String(m);
String v = new String("hello,world");

这些语句会发生什么事情? 大概是这样的:

  1. 会分配一个11长度的char数组,并在常量池分配一个由这个char数组组成的字符串,然后由m去引用这个字符串。
  2. 用n去引用常量池里边的字符串,所以和n引用的是同一个对象。
  3. 生成一个新的字符串,但内部的字符数组引用着m内部的字符数组。
  4. 同样会生成一个新的字符串,但内部的字符数组引用常量池里边的字符串内部的字符数组,意思是和u是同样的字符数组。

如果我们使用一个图来表示的话,情况就大概是这样的(使用虚线只是表示两者其实没什么特别的关系):

对象在内存中的布局

结论就是,m和n是同一个对象,但m,u,v都是不同的对象,但都使用了同样的字符数组,并且用equal判断的话也会返回true。

我们可以使用反射修改字符数组来验证一下效果,可以试试下面的测试代码:

@Test
public void test1() throws Exception {
    String m = "hello,world";
    String n = "hello,world";
    String u = new String(m);
    String v = new String("hello,world");

    Field f = m.getClass().getDeclaredField("value");
    f.setAccessible(true);
    char[] cs = (char[]) f.get(m);
    cs[0] = 'H';
    
    String p = "Hello,world";
    Assert.assertEquals(p, m);
    Assert.assertEquals(p, n);
    Assert.assertEquals(p, u);
    Assert.assertEquals(p, v);
}

从上面的例子可以看到,经常说的字符串是不可变的,其实和其他的final类还是没什么区别,还是引用不可变的意思。 虽然String类不开放value,但同样是可以通过反射进行修改,只是通常没人这么做而已。 即使是涉及”修改”的方法,都是通过产生一个新的字符串对象来实现的,例如replace、toLower、concat等。 这样做的好处就是让字符串是一个状态不可变类,在多线程操作时没有后顾之忧。

当然,在字符串修改的时候,会产生一个新的对象,如果执行很频繁,就会导致大量对象的创建,性能问题也就随之而来了。 为了应付这个问题,通常我们会采用StringBuffer或StringBuilder类来处理。

另外,字符串常量通常是在编译的时候就确定好的,定义在类的方法区里边,也就是说,不同的类,即使用了同样的字符串, 还是属于不同的对象。所以才需要通过引用字符串常量来减少相同的字符串的数量。可以通过下面的代码来测试一下:

class A {
    public void print() {
        System.out.println("hello");
    }
}

class B {
    public void print() {
        String s = "hello";
        // 修改s的第一个字符为H
        System.out.println("hello"); // 输出Hello
        new A().print(); // 输出hello
    }
}

字符串操作细节

String类内部处理有个字符数组之外,还使用偏移位置offset和长度count, 通过offset和count来确定字符数组的一部分,这部分才是这个字符串的真正的内容。 例如,有substring这个常用方法,看下面的例子:

String m = "hello,world";
String u = m.substring(2,10);
String v = u.substring(4,7);

按照上面的说法,m,n的数据结构就如下图所示:

substring在内存中的布局

可以发现,m,n,v是三个不同的字符串对象,但引用的value数组其实是同一个。 同样可以通过上述反射的代码进行验证,这里就不详述了。

但字符串操作时,可能需要修改原来的字符串数组内容或者原数组没法容纳的时候,就会使用另外一个新的数组,例如replace,concat,+等操作。另外,oracle的JDK实现中,String的构造方法,对于字符串参数只是引用部分字符数组的情况(count小于字符数组长度),采用的是拷贝新数组的方式,是比较特别的,不过这个构造方法也没什么机会使用到。

例如下面的代码:

String m = "hello,";
String u = m.concat("world");
String v = new String(m.substring(0,2));

得到的结构图如下:

新字符数组在内存中的布局

可以发现,m,u,v内部的字符数组并不是同一个,有兴趣可以试验一下。

常量池中字符串的产生

常量池中的字符串通常是通过字面量的方式产生的,就像上述m语句那样。 并且他们是在编译的时候就准备好了,类加载的时候,顺便就在常量池生成。

可以通过javap命令检查一下class的字节码,可以发现下面的高亮部分(以上面代码为例):

 javap -v StringTest
 
 Compiled from "StringTest.java"
 public class com.github.mccxj.StringTest extends java.lang.Object
   SourceFile: "StringTest.java"
   minor version: 0
   major version: 50
   Constant pool:
 const #1 = Method       #9.#28; //  java/lang/Object."<init>":()V
+ const #2 = String       #29;    //  hello,
+ const #3 = String       #30;    //  world
 ...
+ const #46 = Asciz       hello,;
+ const #47 = Asciz       world;
 ...

大家不知有没有发现,上面的图中,u和v的字符数组没有被常量池里边的字符串引用到。 原因就是这些字符串(字符数组)都是运行时生成的,而常量池里边的字符串和字符数组是完整对应上的(count等于数组长度)。

即使是字符串的内容是一样的,都不能保证是同一个字符串数组。例如下面的代码:

String m = "hello,world";
String u = m + ".";
String v = "hello,world.";

u和v虽然是一样内容的字符串,但内部的字符数组不是同一个。画成图的话就是这样的:

不同字符数组在内存中的布局

另外有一点,如果让m声明为final,你就会发现u和v变成是同一个对象。画成图的话就是这样的:

u和v在内存中的布局

这应该怎么解释的?这其实都是编译器搞的鬼,因为m是final的, u直接被编译成”hello,world.”了,如果使用javap查看的话,会发现下面一段逻辑:

const #2 = String       #25;    //  hello,world
const #3 = String       #26;    //  hello,world.
...
public void test1()   throws java.lang.Exception;
  Code:
   Stack=1, Locals=4, Args_size=1
   0:   ldc     #2; //String hello,world
   2:   astore_1
   3:   ldc     #3; //String hello,world.
   5:   astore_2
   6:   ldc     #3; //String hello,world.
   8:   astore_3
   9:   return

那么,如何让运行时产生的字符串放到常量池里边呢? 可以借助String类的intern方法。 例如下面的用法

String m = "hello,world";
String u = m.substring(0,2);
String v = u.intern();

上面我们已经知道m,n使用的是同一个字符数组,但intern方法会到常量池里边去寻找字符串”he”,如果找到的话,就直接返回该字符串, 否则就在常量池里边创建一个并返回,所以v使用的字符数组和m,n不是同一个。画成图的话就是这样的:

intern在内存中的布局

字符串的内存释放问题

像字面量字符串,因为存放在常量池里边,被常量池引用着,是没法被GC的。例如下面的代码:

String m = "hello,world";
String n = m.substring(0,2);

m = null;
n = null;

经过上述的操作,画成图的话就是这样的:

内存释放后的布局

而经过上面的分析,我们知道像substring、split等方法得到的结果都是引用原字符数组的。 如果某字符串很大,而且不是在常量池里存在的,当你采用substring等方法拿到一小部分新字符串之后,长期保存的话(例如用于缓存等), 会造成原来的大字符数组意外无法被GC的问题。

关于这个问题,常见的解决办法就是使用new String(String original)或java.io.StreamTokenizer类。并且在网上已经有比较广泛的讨论,大家可以去阅读一下:

结论

  • 任何时候,比较字符串内容都应该使用equals方法
  • 修改字符串操作,应该使用StringBuffer,StringBuilder
  • 可以使用intern方法让运行时产生字符串的复用常量池中的字符串
  • 字符串操作可能会复用原字符数组,在某些情况可能造成内存泄露的问题

性能优化:Trove集合库

1 初见Trove

昨天在Startup News上看到一篇文章:优化技巧分享:把内存消耗降低至原来的1/20。里边提到了一个案例,Java应用中如何降低内存消耗,总结了他的优化过程:

  • 开始时,存放1.3M个Person对象,消耗堆空间1.5GB
  • 修改为java.util.HashMap<Long, Person>进行缓存,从1.5GB降低为214MB
  • 修改HashMap为Trove的TLongObjectHashMap,从214MB降低为143MB
  • 优化Person内部结构,减少重复字段,从143MB降低为93MB
  • 开启64位JDK的XX:UseCompressedOops参数进行指针压缩,从93MB降低为73MB

优化经常得针对具体的场景、数据特性来优化,上述提到的Trove集合库就是这么一个典型例子,它针对的是JDK集合类中处理原生类型的场景。

2 使用Trove

  • 如果使用Maven的话,可使用下面的配置
<dependency>
	<groupId>net.sf.trove4j</groupId>
	<artifactId>trove4j</artifactId>
	<version>3.0.3</version>
</dependency>
  • 常用方法和JDK集合类是一样的,方便迁移
TIntObjectMap<String> ints = new TIntObjectHashMap<String>();
ints.put(100, "John");
ints.put(101, "Tom");
System.out.println(ints.get(100));

Trove相当于把JDK集合类都针对原生类型处理了一遍,例如int,常见的类有 TIntList、TIntObjectMap、TObjectIntMap、TIntSet,可想而知,**维护Trove的工作量是挺大的**。

Trove还提供了开放寻址法的Map,Set,LinkedList实现,可以参考Enhance Collection Performance with this Treasure Trove的做法,类似于:

public class CollectionFactory {
	static boolean useTrove = true;

    /**
	 *  Return a hashmap based on the properties
	 */
	public static Map getHashMap() {
		if ( useTrove ) return new THashMap();
		else            return new HashMap();
	}

	/**
	 *  Return a hashset based on the properties
	 */
	public static Set getHashSet() {
		if ( useTrove ) return new THashSet();
		else            return new HashSet();
	}

	/**
	 *  Return a linkedlist based on the properties
	 */
	public static List getLinkedList() {
		if ( useTrove ) return new TLinkedList();
		else            return new LinkedList();
	}
}
  • 迭代集合中的元素

Trove不推荐JDK的entryXX的做法,而是采用了forEach的回调方式。 代码显得更好看些,另外内存方面也有优势,因为使用entryXX的做法,需要创建一个新的数组。

TIntObjectMap<String> ints = new TIntObjectHashMap<String>();
ints.put(100, "John");
ints.put(101, "Tom");
ints.forEachEntry(new TIntObjectProcedure<String>() {
    public boolean execute(int a, String b) {
        System.out.println("key: " + a + ", val: " + b);
        return true;
    }
});
ints.forEachKey(new TIntProcedure() {
    public boolean execute(int value) {
        System.out.println("key: " + value);
        return true;
    }
});
ints.forEachValue(new TObjectProcedure<String>() {
    public boolean execute(String object) {
        System.out.println("val: " + object);
        return true;
    }
});
  • 自定义Hash策略

我们知道,在JDK集合类里边,有时候是没法自定义Hash策略的,例如String。 不过Trove提供了自定义Hash策略的功能,让你可以根据数据特性进行优化

public static void main(String[] args) {
    char[] foo = new char[]{'a', 'b', 'c'};
    char[] bar = new char[]{'a', 'b', 'c'};
    TCustomHashMap<char[], String> ch = new TCustomHashMap<char[], String>(new CharArrayStrategy());
    ch.put(foo, "John");
    ch.put(bar, "Tom");
}

class CharArrayStrategy implements HashingStrategy<char[]> {
    public int computeHashCode(char[] c) {
        // use the shift-add-xor class of string hashing functions
        // cf. Ramakrishna and Zobel, "Performance in Practice
        // of String Hashing Functions"
        int h = 31; // seed chosen at random
        for (int i = 0; i < c.length; i++) { // could skip invariants
            h = h ^ ((h << 5) + (h >> 2) + c[i]); // L=5, R=2 works well for
                                                  // ASCII input
        }
        return h;
    }

    public boolean equals(char[] c1, char[] c2) {
        if (c1.length != c2.length) { // could drop this check for fixed-length
                                      // keys
            return false;
        }
        for (int i = 0, len = c1.length; i < len; i++) { // could skip
                                                         // invariants
            if (c1[i] != c2[i]) {
                return false;
            }
        }
        return true;
    }
}

3 Trove内幕

Trove是以减少内存消耗为主要目的的,同时也要保持性能。我们这里简单描述一下Trove的实现内幕。 这里有有另外一篇文章可以参考:性能观察: Trove 集合类

  • 直接使用原生类型,而不是包装类型

JDK5的自动封箱机制,让我们可以暂时忽略原生类型和包准类型的区别。自动封箱机制只是一种语法糖,实际上并没有提高效率。 直接使用原生类型替代包装类型,明显可以占用更小的内存、运行起来也更有效率。对于基本类型的集合组合,Trove都提供了 等价的集合类。

  • 使用开放寻址法,而不是链地址法

大多数的JDK集合类都是采用链地址法实现的,它需要一个地址表,并且元素之间需要链表结点,而Trove采用开放寻址法, 虽然需要保持足够的空闲位置(装载因子小于0.5),但因为不需要链表结点,所以总体上内存占用要更少,性能还要更快一些。

  • HashSet不再通过内置HashMap实现

JDK的HashSet是通过内置一个HashSet来实现的,所以白白浪费了value的空间。 Trove提供的THashSet和其他基本类型的HashSet,都不再采用这种方式,直接使用开放地址存储。

  • 采用素数长度大小的数组

为了最大程度避免hash冲突,除了保持较小的装载因子,还采用了素数长度大小的数组。具体见gnu.trove.impl.PrimeFinder

  • 采用代码生成进行维护

虽然这个和性能没什么关系。但是我们也知道要维护这么多的原生类型集合类,重复的逻辑多但没法重用,是个很纠结的事情。 Trove采用代码模板,生成大量的类,通过这种方式,可以大大减少维护的工作量。

4 总结

JDK作为通用集合类,大多数情况下我们还是会优先选择的。不过,在一些性能敏感的地方,或者Trove可以提供更好的选择。 作为靠谱的java开发人员,Trove应该像apache commons、google guava那样,存放在你的工具箱里边。

Web开发利器-Fiddler简介

1 什么是Fiddler?

什么是Fiddler

Fiddler是一个http调试代理,以代理服务器的方式,监听系统的Http网络数据流动, Fiddler可以也可以让你检查所有的http通讯,设置断点,以及Fiddle所有的“进出”的数据。

Fiddler还包含一个简单却功能强大的基于JScript .NET 事件脚本子系统,它可以支持众多的http调试任务。 你是不是曾经疑惑过你的web程序和IE是如何交互的?你是不是遇到过一些奇怪的而你又无法解决的性能瓶颈? 你是不是对那些发送给服务器端的cookie和那些你下载下来的被标记为可缓存的内容感到好奇? 无论你是从事什么开发,哪种语言,只要你想更深入的了解HTTP,这个工具就值得你去了解,它对前端开发工作是很有价值的。

Fiddler官方网站及下载可以在[http://www.fiddler2.com/fiddler2/]找到,安装过程很简单,这里就不介绍了。 同样,Fiddler支持插件扩展,常见插件可以在[http://fiddler2.com/add-on]找到。下面,简单介绍Fiddler的功能和常见应用场景。

2 Fiddler界面及功能介绍

Fiddler界面及功能介绍

Fiddler整个界面布局如上所示,下面再简单介绍一些特殊的概念:

代理模式,支持缓存模式和流模式:

  • 缓冲模式(Buffering Mode Fiddler直到HTTP响应完成时才将数据返回给应用程序。 可以控制响应,修改响应数据。但是时序图有时候会出现异常。
  • 流模式(Streaming Mode): Fiddler 会即时将HTTP响应的数据返回给应用程序。 更接近真实浏览器的性能。时序图更准确。但是不能控制响应。

断点类型,支持请求断点和响应断点:

  • 请求断点: 在向目标服务器发送请求前截获。
  • 响应断点: 在将结果返回到应用程序前截获。此时如果使用的是流模式,则此断点类型将失效。

3 常见案例介绍

快速定位问题页面

有些复杂页面,具有多层嵌套页面或者大量Ajax交互,甚至于模态窗口等,都可能让你无法定位请求路径、问题所在页面等。 借助于Fiddler的请求会话查询功能,可以让你一揽全局,无需逐个页面进行查找。

第一步:使用Ctrl+X清空会话列表,再刷新页面

清空会话列表

第二步:使用Ctrl+F弹出搜索框,输入关键字进行查询

弹出搜索框

第三步:参看具体会话缩小定位范围

缩小定位范围

第四步: 定位到具体请求,进行下一步处理

接下来可以考虑使用AutoResponse进行快速修复验证,或者根据请求路径反查后台逻辑。

使用AutoResponse快速修复验证

在日常开发工作中,有时侯会发现测试环境中某个html/css/javascript文件有问题。 我们利用Fiddler可以修改HTTP数据的特性,非常方便的定位问题并进行验证。

第一步:使用Fiddler查看页面的数据流列表,找到js文件保存到本地

保存到本地

第二步:创建重定向规则,使用本地文件

使用本地文件

第三步:刷新页面,如果看到灰色背景的请求会话,就表示生效了

刷新页面

第四步:修改本地文件,进行测试

修改本地文件之后,重新刷新页面,就可以看到修改后的效果了。 这种调试方式不需要发布到线上再验证,避免了修改不成功、对用户造成影响的风险, 而且不需要搭建复杂的开发服务器等开发环境,非常适合快速web调试。

使用Composer模拟报文发送

有时候在做一些长流程页面、Web服务接口调试时,为了避免修改后重新发起调用的时间过长,可以通过Composer构造请求报文进行快速测试。 等接口调通之后再进行集成测试,可以有效的提高开发和测试的效率。

第一步:拖拽相应的请求会话到Composer页面,会自动生成请求报文

自动生成请求报文

第二步:修改请求报文,然后按Execute进行发送

例如,我去掉Cookie中的JESSIONID,重新发送可以看到多了两次请求会话信息。

修改请求报文

第三步:检查响应报文,验证结果

例如: 我去掉Cookie中的JESSIONID,应该会被跳转到登录页面

验证结果

除了用来做功能快速调试之外,还可以用来做一些安全方面的测试工作, 例如构造一些xss注入、SQL注入报文,看看应用能否妥善处理。

观察页面性能

大多数情况下,一个页面会有好几个请求,除了html页面,还有js/css/图片等。 但是IE等浏览器不能很方便的观察到页面加载的情况,例如每个请求消耗的时间等。 如果使用Fiddler的话,可以使用Statistic视图和Timeline视图,观察页面加载情况,便于定位页面性能瓶颈。

第一步:选择一个或多个请求,根据Statistic视图查看统计时间

查看统计时间

第二步: 选择一个或多个请求,根据Timeline视图查看加载流程

查看加载流程

模拟特殊场景

例如在广东XX项目中,各地市使用的域名是不一样的,有些逻辑根据域名来进行特殊处理。为了模拟这种场景,可以考虑修改本地hosts文件。 不过修改hosts需要重启浏览器,比较麻烦。使用Fiddler的hosts设置功能,就能很方便的模拟。

第一步:选择Tools->HOSTS功能,设置相应的域名映射

设置相应的域名映射

第二步:直接使用域名访问,验证功能

验证功能

Fiddler提供大量的规则允许你模拟各类场景,你甚至可以自定义规则,值得大家深入探讨,多实践多思考。例如:

  • 通过GZIP压缩,测试性能
  • 模拟Agent测试,查看服务端是否对不同客户端定制响应
  • 模拟慢速网络,测试页面的容错性
  • 禁用缓存,方便调试一些静态文件或测试服务端响应情况
  • 根据一些场景自定义规则

模拟各类场景

4 总结

本文简单介绍了Fiddler的常见应用场景。目前,Fiddler在我们项目的团队中广泛使用。

理解RESTFul架构

1 什么是REST

REST全称是Representational State Transfer,中文意思是表述性状态转移。 它首次出现在2000年Roy Fielding的博士论文中,Roy Fielding是 HTTP 规范的主要编写者之一。 他在论文中提到:“我这篇文章的写作目的,就是想在符合架构原理的前提下,理解和评估以网络为基础的应用软件的架构设计,得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。” 如果一个架构符合REST的约束条件和原则,我们就称它为RESTful架构。

REST本身并没有创造新的技术、组件或服务,而隐藏在RESTful背后的理念就是使用Web的现有特征和能力, 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深, 但是理论上REST架构风格并不是绑定在HTTP上,只不过目前HTTP是唯一与REST相关的实例。 所以我们这里描述的REST也是通过HTTP实现的REST。

2 理解RestFul

要理解RESTful架构,需要理解Representational State Transfer这个词组到底是什么意思,它的每一个词都有些什么涵义。 下面我们结合REST原则,围绕资源展开讨论,从资源的定义、获取、表述、关联、状态变迁等角度,列举一些关键概念并加以解释:

  • 资源与URI
  • 统一资源接口
  • 资源的表述
  • 资源的链接
  • 状态的转移

2.1 资源与URI

REST全称是表述性状态转移,那究竟指的是什么的表述? 其实指的就是资源。**任何事物,只要有被引用到的必要,它就是一个资源。资源可以是实体(例如手机号码),也可以只是一个抽象概念(例如价值) **。下面是一些资源的例子:

  • 某用户的手机号码
  • 某用户的个人信息
  • 最多用户订购的GPRS套餐
  • 两个产品之间的依赖关系
  • 某用户可以办理的优惠套餐
  • 某手机号码的潜在价值

要让一个资源可以被识别,需要有个唯一标识,在Web中这个唯一标识就是URI(Uniform Resource Identifier)。 URI既可以看成是资源的地址,也可以看成是资源的名称。如果某些信息没有使用URI来表示,那它就不能算是一个资源, 只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则,具有自描述性,需要在形式上给人以直觉上的关联。这里以github网站为例,给出一些还算不错的URI:

  • https://github.com/git
  • https://github.com/git/git
  • https://github.com/git/git/blob/master/block-sha1/sha1.h
  • https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08
  • https://github.com/git/git/pulls
  • https://github.com/git/git/pulls?state=closed
  • https://github.com/git/git/compare/master…next

下面让我们来看看URI设计上的一些技巧:

  • 使用_或-来让URI可读性更好

曾经Web上的URI都是冰冷的数字或者无意义的字符串,但现在越来越多的网站使用_或-来分隔一些单词,让URI看上去更为人性化。 例如国内比较出名的开源中国社区,它上面的新闻地址就采用这种风格, 如http://www.oschina.net/news/38119/oschina-translate-reward-plan。

  • 使用/来表示资源的层级关系

例如上述/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08就表示了一个多级的资源, 指的是git用户的git项目的某次提交记录,又例如/orders/2012/10可以用来表示2012年10月的订单记录。

  • 使用?用来过滤资源

很多人只是把?简单的当做是参数的传递,很容易造成URI过于复杂、难以理解。可以把?用于对资源的过滤, 例如/git/git/pulls用来表示git项目的所有推入请求,而/pulls?state=closed用来表示git项目中已经关闭的推入请求, 这种URL通常对应的是一些特定条件的查询结果或算法运算结果。

  • ,或;可以用来表示同级资源的关系

有时候我们需要表示同级资源的关系时,可以使用,或;来进行分割。例如哪天github可以比较某个文件在随意两次提交记录之间的差异, 或许可以使用/git/git /block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d675913d08; bd63e61bdf38e872d5215c07b264dcc16e4febca作为URI。 不过,现在github是使用…来做这个事情的,例如/git/git/compare/master…next。

2.2 统一资源接口

RESTFul架构应该遵循统一接口原则,统一接口包含了一组受限的预定义的操作,不论什么样的资源,都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET,PUT和POST,并遵循这些方法的语义。

如果按照HTTP方法的语义来暴露资源,那么接口将会拥有安全性和幂等性的特性,例如GET和HEAD请求都是安全的, 无论请求多少次,都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的,无论对资源操作多少次, 结果总是一样的,后面的请求并不会产生比第一次更多的影响。

下面列出了GET,DELETE,PUT和POST的典型用法:

GET

  • 安全且幂等
  • 获取表示
  • 变更时获取表示(缓存)

  • 200(OK) - 表示已在响应中发出
  • 204(无内容) - 资源有空表示
  • 301(Moved Permanently) - 资源的URI已被更新
  • 303(See Other) - 其他(如,负载均衡)
  • 304(not modified)- 资源未更改(缓存)
  • 400 (bad request)- 指代坏请求(如,参数错误)
  • 404 (not found)- 资源不存在
  • 406 (not acceptable)- 服务端不支持所需表示
  • 500 (internal server error)- 通用错误响应
  • 503 (Service Unavailable)- 服务端当前无法处理请求

POST

  • 不安全且不幂等
  • 使用服务端管理的(自动产生)的实例号创建资源
  • 创建子资源
  • 部分更新资源
  • 如果没有被修改,则不过更新资源(乐观锁)

  • 200(OK)- 如果现有资源已被更改
  • 201(created)- 如果新资源被创建
  • 202(accepted)- 已接受处理请求但尚未完成(异步处理)
  • 301(Moved Permanently)- 资源的URI被更新
  • 303(See Other)- 其他(如,负载均衡)
  • 400(bad request)- 指代坏请求
  • 404 (not found)- 资源不存在
  • 406 (not acceptable)- 服务端不支持所需表示
  • 409 (conflict)- 通用冲突
  • 412 (Precondition Failed)- 前置条件失败(如执行条件更新时的冲突)
  • 415 (unsupported media type)- 接受到的表示不受支持
  • 500 (internal server error)- 通用错误响应
  • 503 (Service Unavailable)- 服务当前无法处理请求

PUT

  • 不安全但幂等
  • 用客户端管理的实例号创建一个资源
  • 通过替换的方式更新资源
  • 如果未被修改,则更新资源(乐观锁)

  • 200 (OK)- 如果已存在资源被更改
  • 201 (created)- 如果新资源被创建
  • 301(Moved Permanently)- 资源的URI已更改
  • 303 (See Other)- 其他(如,负载均衡)
  • 400 (bad request)- 指代坏请求
  • 404 (not found)- 资源不存在
  • 406 (not acceptable)- 服务端不支持所需表示
  • 409 (conflict)- 通用冲突
  • 412 (Precondition Failed)- 前置条件失败(如执行条件更新时的冲突)
  • 415 (unsupported media type)- 接受到的表示不受支持
  • 500 (internal server error)- 通用错误响应
  • 503 (Service Unavailable)- 服务当前无法处理请求

DELETE

  • 不安全但幂等
  • 删除资源

  • 200 (OK)- 资源已被删除
  • 301 (Moved Permanently)- 资源的URI已更改
  • 303 (See Other)- 其他,如负载均衡
  • 400 (bad request)- 指代坏请求
  • 404 (not found)- 资源不存在
  • 409 (conflict)- 通用冲突
  • 500 (internal server error)- 通用错误响应
  • 503 (Service Unavailable)- 服务端当前无法处理请求

下面我们来看一些实践中常见的问题:

  • POST和PUT用于创建资源时有什么区别?

POST和PUT在创建资源的区别在于,所创建的资源的名称(URI)是否由客户端决定。 例如为我的博文增加一个java的分类,生成的路径就是分类名/categories/java,那么就可以采用PUT方法。 不过很多人直接把POST、GET、PUT、DELETE直接对应上CRUD,例如在一个典型的rails实现的RESTFul应用中就是这么做的。 我认为,这是因为rails默认使用服务端生成的ID作为URI的缘故,而不少人就是通过rails实践REST的,所以很容易造成这种误解。

  • 客户端不一定都支持这些HTTP方法吧?

的确有这种情况,特别是一些比较古老的基于浏览器的客户端,只能支持GET和POST两种方法。 在实践上,客户端和服务端都可能需要做一些妥协。例如rails框架就支持通过隐藏参数_method=DELETE来传递真实的请求方法, 而像Backbone这样的客户端MVC框架则允许传递_method传输和设置X-HTTP-Method-Override头来规避这个问题。

  • 统一接口是否意味着不能扩展带特殊语义的方法?

统一接口并不阻止你扩展方法,只要方法对资源的操作有着具体的、可识别的语义即可,并能够保持整个接口的统一性。 像WebDAV就对HTTP方法进行了扩展,增加了LOCK、UPLOCK等方法。而github的API则支持使用PATCH方法来进行issue的更新,例如:

PATCH /repos/:owner/:repo/issues/:number

不过,需要注意的是,像PATCH这种不是HTTP标准方法的,服务端需要考虑客户端是否能够支持的问题。

  • 统一资源接口对URI有什么指导意义?

统一资源接口要求使用标准的HTTP方法对资源进行操作,所以URI只应该来表示资源的名称,而不应该包括资源的操作。 通俗来说,URI不应该使用动作来描述。例如,下面是一些不符合统一接口要求的URI:

  • GET /getUser/1
  • POST /createUser
  • PUT /updateUser/1
  • DELETE /deleteUser/1

  • 如果GET请求增加计数器,这是否违反安全性?

安全性不代表请求不产生副作用,例如像很多API开发平台,都对请求流量做限制。像github,就会限制没有认证的请求每小时只能请求60次。 但客户端不是为了追求副作用而发出这些GET或HEAD请求的,产生副作用是服务端“自作主张”的。 另外,服务端在设计时,也不应该让副作用太大,因为客户端认为这些请求是不会产生副作用的。

  • 直接忽视缓存可取吗?

即使你按各个动词的原本意图来使用它们,你仍可以轻易禁止缓存机制。 最简单的做法就是在你的HTTP响应里增加这样一个报头: Cache-control: no-cache。 但是,同时你也对失去了高效的缓存与再验证的支持(使用Etag等机制)。 对于客户端来说,在为一个REST式服务实现程序客户端时,也应该充分利用现有的缓存机制,以免每次都重新获取表示。

  • 响应代码的处理有必要吗?

如上图所示,HTTP的响应代码可用于应付不同场合,正确使用这些状态代码意味着客户端与服务器可以在一个具备较丰富语义的层次上进行沟通。 例如,201(“Created”)响应代码表明已经创建了一个新的资源,其URI在Location响应报头里。 假如你不利用HTTP状态代码丰富的应用语义,那么你将错失提高重用性、增强互操作性和提升松耦合性的机会。 如果这些所谓的RESTFul应用必须通过响应实体才能给出错误信息,那么SOAP就是这样的了,它就能够满足了。

2.3 资源的表述

上面提到,客户端通过HTTP方法可以获取资源,是吧? 不,确切的说,客户端获取的只是资源的表述而已。 资源在外界的具体呈现,可以有多种表述(或成为表现、表示)形式,在客户端和服务端之间传送的也是资源的表述,而不是资源本身。 例如文本资源可以采用html、xml、json等格式,图片可以使用PNG或JPG展现出来。 资源的表述包括数据和描述数据的元数据,例如,HTTP头“Content-Type” 就是这样一个元数据属性。

那么客户端如何知道服务端提供哪种表述形式呢?

答案是可以通过HTTP内容协商,客户端可以通过Accept头请求一种特定格式的表述,服务端则通过Content-Type告诉客户端资源的表述形式。

以github为例,请求某组织资源的json格式的表述形式:

json格式

假如github也能够支持xml格式的表述格式,那么结果就是这样的:

xml格式

下面我们来看一些实践上常见的设计:

  • 在URI里边带上版本号

有些API在URI里边带上版本号,例如:

  • http://api.example.com/1.0/foo
  • http://api.example.com/1.2/foo
  • http://api.example.com/2.0/foo

如果我们把版本号理解成资源的不同表述形式的话,就应该只是用一个URL,并通过Accept头部来区分,还是以github为例,它的Accept的完整格式是

application/vnd.github[.version].param[+json]

对于v3版本的话,就是Accept: application/vnd.github.v3。对于上面的例子,同理可以使用使用下面的头部:

  • Accept: vnd.example-com.foo+json; version=1.0
  • Accept: vnd.example-com.foo+json; version=1.2
  • Accept: vnd.example-com.foo+json; version=2.0

  • 使用URI后缀来区分表述格式

像rails框架,就支持使用/users.xml或/users.json来区分不同的格式。 这样的方式对于客户端来说,无疑是更为直观,但混淆了资源的名称和资源的表述形式。 我个人认为,还是应该优先使用内容协商来区分表述格式。

  • 如何处理不支持的表述格式

当服务器不支持所请求的表述格式,那么应该怎么办?若服务器不支持,它应该返回一个HTTP 406响应,表示拒绝处理该请求。下面以github为例,展示了一个请求XML表述资源的结果:

不支持的格式

2.4 资源的链接

我们知道REST是使用标准的HTTP方法来操作资源的,但仅仅因此就理解成带CURD的Web数据库架构就太过于简单了。 这种反模式忽略了一个核心概念: “超媒体即应用状态引擎(hypermedia as the engine of application state)”。 超媒体是什么? 当你浏览Web网页时,从一个连接跳到一个页面,再从另一个连接跳到另外一个页面,就是利用了超媒体的概念: 把一个个把资源链接起来.

要达到这个目的,就要求在表述格式里边加入链接来引导客户端。在《RESTFul Web Services》一书中,作者把这种具有链接的特性成为连通性。下面我们具体来看一些例子。

下面展示的是github获取某个组织下的项目列表的请求,可以看到在响应头里边增加Link头告诉客户端怎么访问下一页和最后一页的记录。 而在响应体里边,用url来链接项目所有者和项目地址。

用url来链接

又例如下面这个例子,创建订单后通过链接引导客户端如何去付款。

引导客户端

上面的例子展示了如何使用超媒体来增强资源的连通性。很多人在设计RESTFul架构时,使用很多时间来寻找漂亮的URI,而忽略了超媒体。所以,应该多花一些时间来给资源的表述提供链接,而不是专注于“资源的CRUD”。

2.5 状态的转移

有了上面的铺垫,再讨论REST里边的状态转移就会很容易理解了。 不过,我们先来讨论一下REST原则中的无状态通信原则。初看一下,好像自相矛盾了,既然无状态,何来状态转移一说?

其实,这里说的无状态通信原则,并不是说客户端应用不能有状态,而是指服务端不应该保存客户端状态。

2.5.1 应用状态与资源状态

实际上,状态应该区分应用状态和资源状态,客户端负责维护应用状态,而服务端维护资源状态。 客户端与服务端的交互必须是无状态的,并在每一次请求中包含处理该请求所需的一切信息。 服务端不需要在请求间保留应用状态,只有在接受到实际请求的时候,服务端才会关注应用状态。 这种无状态通信原则,使得服务端和中介能够理解独立的请求和响应。 在多次请求中,同一客户端也不再需要依赖于同一服务器,方便实现高可扩展和高可用性的服务端。

但有时候我们会做出违反无状态通信原则的设计,例如利用Cookie跟踪某个服务端会话状态,常见的像J2EE里边的JSESSIONID。 这意味着,浏览器随各次请求发出去的Cookie是被用于构建会话状态的。 当然,如果Cookie保存的是一些服务器不依赖于会话状态即可验证的信息(比如认证令牌),这样的Cookie也是符合REST原则的。

2.5.2 应用状态的转移

状态转移到这里已经很好理解了, “会话”状态不是作为资源状态保存在服务端的,而是被客户端作为应用状态进行跟踪的。客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。 这些类似“下一页”之类的链接起的就是这种推进状态的作用–指引你如何从当前状态进入下一个可能的状态。

3 总结

现在广东XXX版本、XXX等项目中均使用传统的RPC、SOAP方式的Web服务,而移动南方基地XXXX项目的后台, 虽然采用了JSON格式进行交互,但还是属于RPC风格的。本文从资源的定义、获取、表述、关联、状态变迁等角度, 试图快速理解RESTFul架构背后的概念。RESTFul架构与传统的RPC、SOAP等方式在理念上有很大的不同,希望本文能对各位理解REST有所帮助。

Goodbye,Google Reader

今天早上,把Google Reader的订阅迁移到鲜果,顺便整理了Reader里边的RSS订阅,略为增长了一点,到153个,主要增加了许多国内著名互联网公司的团队博客。 鲜果是把订阅和RSS订阅分开的,对于我来说,这显得很不习惯。对于鲜果来说,想打造社交阅读平台,又不得不保留RSS订阅这种传统模式,也是挺无奈的。

另外,看过Feng写的那些写过博客的人们,我也发现了有不少人的博客很久之前就停止更新了。 博客这东西,在微博,微信等新媒体的冲击下,更显得步伐缓慢,似乎不适应新时代的要求。但只有这些写下的文字,才显得有点沉淀, 也只有部分通过写博客获得了某些真实东西的人才坚持下来。

分享一下我的RSS订阅.

Google Reader即将关闭,阅读还将继续~