多个资源的REST接口用法 [英] REST interface usage for multiple resources

问题描述

我目前正在通过http向在线服务添加REST API，我遇到了一个非常简单的问题，我无法找到满足我的答案：

I am currently adding a REST API over http to an online service and I am confronted with a very simple problem for which I cannot find an answer that satisfies me:

我主要有2个资源：'用户'和'报告'，因为你会猜到报告与用户相关联（我的数据库中只有一个，=外键）

I have mainly 2 resources: 'user' and 'reports', as you would have guessed reports are associated to users (to one and only one, = foreign key in my db)

无论如何我有这个网址映射 GET ：

Anyway I have this url mapping for GET :

• mywebsite / api / users / {id} ：返回用户及相关信息，如果id不存在则返回用户列表


• mywebsite / api / report / {id} ：如果id不存在，则返回报告和相关信息，或报告列表

• mywebsite/api/users/{id} : returns a user and related information, or a list of users if id is not present
• mywebsite/api/report/{id} : returns a report and related information, or a list of reports if id is not present

现在我想获取特定用户的报告，我现在的做法是在 GET 报告方法：？username = {username} 如果它存在，我过滤结果只返回报告对于这个用户来说。

Now I would like to get the reports for a specific user, my way of doing it now is to add an optional parameter to the GET method for reports: ?username={username} and if it is present, I am filtering the results to return only the reports for this user.

我不禁想到有些事情是错的......如果我开始做这样的事情，我会处理我的方法 GET 完整的if / else查找缺少的参数...

I can't help but think something is wrong... if I start doing things like this I will have my methods handling GET full of if/else looking for missing parameters...

II想到的其他解决方案是：

Other solutions I I thought of are:

• 将报告合并到 mywebsite / api / users / {的结果 GET 中id} 但是我有很多报道，所以最终它会变得非常糟糕...


• 为这个函数映射另一个url，但它只是没有感觉不错......

• incorporate the reports in the resulting GET on mywebsite/api/users/{id} but I have many many reports so in the end it will become really bad...
• map another url just for this function, but it just doesn't feel right...

我只是抓住了这个REST的东西，我喜欢这个概念但是有点解释这件事真的可以帮助我更好地理解它。

I am just getting the grips of this REST thing, I like the concept but a little explanation on this matter would really help me understand it better.

谢谢

编辑：

似乎我在REST世界中遇到了一个常见问题，我已将资源绑定到模型上。如果将资源绑定到模型，则最终会导致聚合属性出现问题。
有人在这里描述了这个错误 http://jacobian.org/writing/rest -worst-practices / 但我还没有理解如何管理它，因为他说...

It seems I have hit a common problem in the REST world, I have tied my resources to a model. If you tie a resource to a model you end up having trouble with aggregate attributes. Some guy describes this error here http://jacobian.org/writing/rest-worst-practices/ but I have yet to understand how to manage that as he said...

fyi我正在使用django /活塞但无论使用何种语言，这个问题都应该是可以回答的。

推荐答案

我可以'帮助，但认为有些事情是错误的...

I can't help but think something is wrong...

你唯一错误的是认为你的URI结构使你的应用程序或多或少RESTful。 原创REST文献从未说过查询字符串不好。人们倾向于挂起URI结构，并且似乎认为你的URI必须以某种方式构建才能被认为是RESTful。使用？username =< username> 没有任何问题。 URI只是一个ID （虽然有些人比其他人更友好）。

The only thing you're doing wrong is thinking that your URI structure makes your application more or less RESTful. The original REST literature never says that query strings are bad. People tend to get hung up on URI structure and seem to think that your URIs must be structured a certain way to be considered RESTful. There is nothing wrong with using ?username=<username>. A URI is just an ID (though some can be more human friendly than others).

底线：不要挂断你的URI 看起来的方式。还有更重要的事情需要关注（推广超链接/超媒体，坚持统一的界面 - 通常是HTTP，可缓存性等）。

Bottom line: don't get hung up on how your URIs look. There are much more important things to focus on (promoting hyperlinking/hypermedia, sticking to a uniform interface - typically HTTP, cacheability, etc.).

这可能很大一个题外话，但至于你对资源与模型耦合的评论，你仍然可以。如果您执行/ reports / ID / user路由，只需将user视为报表模型上的关系名称。当然，您的模型定义了报告与用户之间的关系。您只需解析URI的最后一部分，使其与此关系的名称相匹配。在像你描述的一对一关系的情况下，总是一个好主意也设置 Content-Location 标头，用于匹配用户的规范URI。

This may be a big of a digression but, as for your comment about the coupling of resources to models, you're still okay. If you do go the /reports/ID/user route, just think of 'user' as a relationship name on your reports model. Surely your model defines the relationship between a report and a user. You can just parse the last part of your URI so that it matches the name of this relationship. In the case of one to one relationship like you describe its always a good idea to also set the Content-Location header to match the canonical URI of the user.

例如。说报告123属于用户1.您现在有两种方式来引用此用户：

For example. Say report 123 belongs to user 1. You now have two ways of referring this user:

http://example.com/reports/123/user
http://example.com/user/1

For第一个URI，设置 Content-Location也是个好主意：http：//example.com/user/1 header

For the first URI, it would also be a good idea to set Content-Location: http://example.com/user/1 header

这篇关于多个资源的REST接口用法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！