设计一个REST架构的一些软件准则:
1. 不要使用“物理”的URLs:一些物理的URL指向具体的内容,例如一个XML文件“http://www.acme.com/inventory/product003.xml”。而逻辑URL并不会意味着一个物理文件,例如“http://www.acme.com/inventory/product/003”。
当然,即使有.xml扩展名,内容也是动态生成的。它应该是“人类易于识别的”、逻辑的urls,而不是物理urls。
2. 查询不应该返回一个超负荷数据:如果需要,可以提供分页机制。例如,“产品清单”GET请求应该返回第n个产品(例如,第10),同时带有下/上翻页的链接。
3. REST响应,即便可以是任何东西,也请确保它是有据可查的,确保他不会改变哪怕一点点输出格式(因为改变会对现有的客户端造成破坏)。
请记住,即使是人类可读的输出,但你的客户并不是人类用户;
如果输出是在XML中,确保您将它保存在schema模式或DTD文件中。
4. 不要让客户端构建额外的动作的URL,包括REST响应的实际url。例如,对“产品清单”的请求,可以返回每个产品的ID,规范说,你应该使用http://www.acme.com/product/PRODUCT_ID得到更多的细节,这是一种很糟糕的设计;相反,好的设计中,响应应包括每个产品的实际url地址:http://www.acme.com/product/001263等。
按照这种设计思路,意味着输出会较大。但是,这也意味着您可以轻松地直接对新得到的URL进行按需操作,而不需要改变客户端代码。
5. GET访问请求,不应该引起服务器任何的状态改变。任何服务器状态的改变,都应该是一个POST请求(或其他HTTP动词,如DELETE)造成的。
1. 不要使用“物理”的URLs:一些物理的URL指向具体的内容,例如一个XML文件“http://www.acme.com/inventory/product003.xml”。而逻辑URL并不会意味着一个物理文件,例如“http://www.acme.com/inventory/product/003”。
当然,即使有.xml扩展名,内容也是动态生成的。它应该是“人类易于识别的”、逻辑的urls,而不是物理urls。
2. 查询不应该返回一个超负荷数据:如果需要,可以提供分页机制。例如,“产品清单”GET请求应该返回第n个产品(例如,第10),同时带有下/上翻页的链接。
3. REST响应,即便可以是任何东西,也请确保它是有据可查的,确保他不会改变哪怕一点点输出格式(因为改变会对现有的客户端造成破坏)。
请记住,即使是人类可读的输出,但你的客户并不是人类用户;
如果输出是在XML中,确保您将它保存在schema模式或DTD文件中。
4. 不要让客户端构建额外的动作的URL,包括REST响应的实际url。例如,对“产品清单”的请求,可以返回每个产品的ID,规范说,你应该使用http://www.acme.com/product/PRODUCT_ID得到更多的细节,这是一种很糟糕的设计;相反,好的设计中,响应应包括每个产品的实际url地址:http://www.acme.com/product/001263等。
按照这种设计思路,意味着输出会较大。但是,这也意味着您可以轻松地直接对新得到的URL进行按需操作,而不需要改变客户端代码。
5. GET访问请求,不应该引起服务器任何的状态改变。任何服务器状态的改变,都应该是一个POST请求(或其他HTTP动词,如DELETE)造成的。