一个REST风格的URI设计方案[Blog Web Services]
拿Blog Web Services为例，一个REST风格的URI设计，可行乎？
/blog
get,列表,分页表示/blog?pi={pageindex}
博客分类
/blog/category
get，所有blog分类
post,创建新的分类
/blog/category/{id}
get，blog分类明细
put,修改分类
delete,删除分类
/blog/category/{id},get，blog分类明细,
这个表达是有问题的，某一类别的blog列表？
博客归档
/blog/date
get，？
/blog/date/{year}
get，某年的blog列表
/blog/date/{year}/{month}
get，某月的blog列表
/blog/date/{year}/{month}/{day}
get，某日的blog列表
博客明细
单个blog信息的Read,Update,Delete
Case1:/blog/
post,创建新的blog，而实际上/blog/是列表展示，把创建新blog和blog列表混在一起了。
/blog/{id}
get,读取
put,修改
delete,删除
【NO.1】假设/blog/{id}的id是string类型，那么恰好出现id=category|date的情况呢？
因此，需要加入资源的二级分类标示:
Case2:/blog/details/
post,创建新的blog
/blog/details/{id}
get,读取
put,修改
delete,删除
博客搜索
/blog/search?key={key}
get，搜索
有几个问题需要注意：
1.当设计的url规则需要区分顺序优先级时，是不是就可以认定是一个比较糟糕的设计？
【NO.1】
2.用户截取最后一个url片段，Web仍然能够访问
例如，当用户输入：/blog/details时，如何处理？
给出错误提示？
3.针对类似资源的批量处理
针对类似资源的批量处理，例如，
批量修改，把category=1的blog都改成category=2
/blog
get,列表,分页表示/blog?pi={pageindex}
博客分类
/blog/category
get，所有blog分类
post,创建新的分类
/blog/category/{id}
get，blog分类明细
put,修改分类
delete,删除分类
/blog/category/{id},get，blog分类明细,
这个表达是有问题的，某一类别的blog列表？
博客归档
/blog/date
get，？
/blog/date/{year}
get，某年的blog列表
/blog/date/{year}/{month}
get，某月的blog列表
/blog/date/{year}/{month}/{day}
get，某日的blog列表
博客明细
单个blog信息的Read,Update,Delete
Case1:/blog/
post,创建新的blog，而实际上/blog/是列表展示，把创建新blog和blog列表混在一起了。
/blog/{id}
get,读取
put,修改
delete,删除
【NO.1】假设/blog/{id}的id是string类型，那么恰好出现id=category|date的情况呢？
因此，需要加入资源的二级分类标示:
Case2:/blog/details/
post,创建新的blog
/blog/details/{id}
get,读取
put,修改
delete,删除
博客搜索
/blog/search?key={key}
get，搜索
有几个问题需要注意：
1.当设计的url规则需要区分顺序优先级时，是不是就可以认定是一个比较糟糕的设计？
【NO.1】
2.用户截取最后一个url片段，Web仍然能够访问
例如，当用户输入：/blog/details时，如何处理？
给出错误提示？
3.针对类似资源的批量处理
针对类似资源的批量处理，例如，
批量修改，把category=1的blog都改成category=2
批量删除,把category=1的blog删除
最新版本：http://www.gaotianpu.com/blog/detail/265
