所有
对于我们从.NET开始的新项目,我们想要运行纯REST。因此,我们选择.NET Web API作为.NET Framework 4.5(而不是WCF)的一部分发布,并考虑到它支持纯REST特性。但是,当我们根据我们的要求进行更多探索时,我们意识到它没有提供类似URL格式的REST的URI模板支持。我们仍然没问题,因为我们对WebAPI的查询字符串格式感觉不太好。
当我们聘请一个新团队时,他们开始强制要求他们只需要REST格式的URL格式,因为它是标准规范和喜欢。
当被问及执法时,他们刚刚提到它是一个标准,我们必须遵守它,这并不能说服我。
所以,我有兴趣知道REST架构提供什么样的开箱即用?还有查询字符串格式的URI不符合REST方法吗?
REST URI:http://myapplicationdomain.com/apps/appId
Querystring URI:http://myapplicationdomain.com/GetAps/appId= {appId}
提前致谢。
答案 0 :(得分:5)
REST不仅是URL格式,REST也不限制您使用参数。
REST哲学的一部分是识别资源,因此您的资源具有URL,HTTP动词(Get,Post,Delete,Put等)定义<此资源上的em> operations 。 您仍然可以使用参数,例如
http://myappfomain.com/product/?page=1&pageSize=10
这是对产品列表的GET请求(因为未指定ID),并且在查询字符串中指定了分页/排序条件。这是完全正确的。
或者
http://myappdomain.com/product/123/?format=json
您可以在此处访问ID为#123的产品,但要求将其作为JSON返回。这也很好。
从这个角度来看,资源拥有自己的URL更合乎逻辑。参数可能会添加一些细节。
以这种方式看待它: URI定义主题 HTTP Verb定义操作(怎么做) 查询参数提供了一些细节(如何操作)
希望它有所帮助。
答案 1 :(得分:2)
URI的REST(请参阅wiki Representational state transfer)“样式”是有原因的。来自wiki的摘录:
统一界面
...
资源标识在请求中标识单个资源,例如在基于Web的REST系统中使用URI ....通过这些表示来处理资源当客户端拥有资源的表示时,......它有足够的信息来修改或删除服务器上的资源......
我使用这些引用作为事实的很好的解释,REST样式的URI实际上是关于资源标识。我们可以
1)DB和
中的表
2)允许
的ID列
3)更新或删除记录。
REST中的URI也是这样做的:
1)确定资源类型(实体/表)
2)识别资源ID
3)设置操作
HTTP Method URI Operation
GET \ResourceType\ResourceId SELECT, READ
POST \ResourceType INSERT, Add, create new
PUT \ResourceType\ResourceId UPDATE the record with ResourceID
DELETE \ResourceType\ResourceId DELETE that record
正如我们所看到的,REST URI样式在资源管理
的完整上下文中确实有意义