向客户端呈现 REST Web 服务界面
我的 RESTfull Web 服务中执行搜索操作的资源之一有很多条件/参数。
在当前的实现中，此搜索条件像字典一样传递，以选项助记符作为键。例如，
{'fieldl_greater_equal' : <value>,
'field2_like' : <value>,
...}
问题是：
向我的客户介绍允许的助记符列表和每个助记符的允许值（即系统的界面）的最佳方式是什么？
我应该将这些助记符移至 inurl-parameters 吗？
如何使这样的资源易于扩展？
对于如何实施这样的系统有什么建议和意见吗？
Web 服务是在 Python 上实现的。
One of resources in my RESTfull web-service, which performs a search operation, has a lot of criteria/parameters.
In the current implementation this search criteria is passed like a dictionary with option mnemonics as keys. E.g.
{'fieldl_greater_equal' : <value>,
'field2_like' : <value>,
...}
The questions are:
What is the best way to introduce list of allowed mnemonics and allowed values for each mnemonic (i.e. interface of the system) to my clients?
Should I move those mnemonics to inurl-parameters?
How to make such resource easy-extendable?
Any suggestions and receipts of how such system should be implemented?
Web-service is implementing on Python.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
第一的。 “搜索”几乎可以指任何事物。非常非常清楚 GET 请求的用例是有帮助的。
对于“搜索”，您有三个基本选择。
查询字符串。
?param1=this¶m2=that片段。
#param1=this¶m2=thatURL 路径元素。
/this/that当“搜索”真正使用主键来识别资源时，您可以使用路径元素。路径不会改变。这是资源的身份，而不是某种“搜索”。
Fragment 非常灵活，但也处于 RESTful URI 处理的边缘。您可能应该避免使用它。
大多数人在想到“搜索”而不是“识别”资源时会想到查询字符串。
然而，您的 URL 组件可能相当复杂。我在 URL 中使用了类似
/in;param1=this;param2=that/的语法来提供更灵活的资源标识。我们声称 URI 会主动（且始终）定位资源。 “在”的意思是包括。我们用“ex”来表示排除。我尝试避免使用
?param1=this¶m2=that查询字符串来标识资源。我认为它应该将其用于页码和其他对于识别资源并不重要的内容。无论您做什么，都需要提供允许的
param名称及其解释的列表。这是“元数据”，您可以实现元数据 REST 请求。您定义一些“/api”或“/meta”API，它们提供有关 URI、参数以及它们如何组合在一起的信息。
First. "search" can mean almost anything. It helps to be very, very clear on what the use case is for your GET request.
You have three essential choices for "search".
Query String.
?param1=this¶m2=thatFragment.
#param1=this¶m2=thatURL path element.
/this/thatThe Path Element is something you use when the "search" is really using the primary keys to identify the resource. Paths don't change. This is the identity of the resource more than some kind of "search".
The Fragment is the very flexible, but also lives at the fringes of RESTful URI processing. You should probably avoid using it.
The Query String is what most folks think of when they think of "search" instead of "identification" of a resource.
Your URL components, however, can be fairly complex things. I've used a syntax like
/in;param1=this;param2=that/in a URL to provide more flexible identification of resources. We were making a claim that the URI would positively (and always) locate the resources. The "in" meant include. We had "ex" for exclude.I try to avoid using
?param1=this¶m2=thatquery string to identify a resource. I think it should used it for page numbers and other things that were not essential for identifying the resources.No matter what you do, you need to provide a list of allowed
paramnames and their interpretation. This is "metadata" and you can implement Metadata REST requests.You define some "/api" or "/meta" API's which provide the information on the URI's, the parameters and how it all fits together.
描述 REST Web 服务的一种方法是提供一个 WADL 来描述如何访问该服务。对于允许值的描述，您可以使用某种模式定义（JSON 或 XML），它允许定义这些值的枚举。
这种方法将允许自动验证，而您始终可以提供自由文本描述以及额外的说明示例。
One way to describe a REST webservice is by providing a WADL that describes how the service can be accessed. For a description of allowed values you could use some sort of schema definition (either JSON or XML) which allows for the defintion of enumerations of those.
This approach would allow automatic verfication, whereas you can always provide a free text description with illustrating examples in addition.