RESTful Android ContentProvider URI
为了实现 RESTful，获取帖子评论的 URI 应该类似于：
posts/#/comments
其中 # 是帖子 ID，该 ID 将根据您感兴趣的帖子而变化。
我想应用一些约定在设计我的内容提供商的内容 URI 时。问题是，内容提供商的用户如何以优雅的方式构建这样的 URI？
一个可行的解决方案是：
//in PostProvider
public static URI CONTENTS_URI_POSTS = Uri.parse("content://" + AUTHORITY + "/posts");
public static String COMMENTS = "comments";
然后用户将使用 Uri.builder 组合 CONTENTS_URI_POSTS + id + COMMENTS。但是，此方法公开了有关如何构造 URI 的详细信息。
为了隐藏细节，也许我可以添加一个方法：
public static URI buildContentUriToGetPostComments(int post_id);
有更好的主意吗？谢谢！
To be RESTful, the URI to get the comments for a post, should be something like:
posts/#/comments
Where # is the post id that will change depending on which post your are interested in.
I want to apply some convention when designing the content URI of my content provider. The question is, how is the user of the content provider expected to construct such a URI in an elegant way?
A workable solution is :
//in PostProvider
public static URI CONTENTS_URI_POSTS = Uri.parse("content://" + AUTHORITY + "/posts");
public static String COMMENTS = "comments";
Then the user will use Uri.builder to combine CONTENTS_URI_POSTS + id + COMMENTS. However, this method exposes the details on how to construct a URI.
To hide the details, maybe I could add a method:
public static URI buildContentUriToGetPostComments(int post_id);
Any better idea? Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以对帖子及其评论使用不同的路径：
这样您就拥有了一个看起来更传统的 URI，并且在内容提供程序中更易于处理，您不需要解析 URI，但标准的 UriMatcher 就可以了。
You could use different paths for posts and their comments:
This way you have an URI which looks more conventional and its simpler to handle in the content provider, you do not need to parse the URI but a standard UriMatcher will do.
不是要提起旧事，但我在实现这种一对多关系时也遇到了麻烦...如果我遵循 Stefans 方法：
如果我稍后想要添加一个 URI 以通过 id 获取特定评论怎么办？
上面的代码将创建与之前的 URI 相同的匹配。
就我而言，我尝试使用以下方法解决此问题
，但是，此解决方案可能会导致问题。例如，如果我想使用两者加载游标：
并使用：插入注释，
则并非 ContentProvider 的所有用户都会收到通知，因为 URI 模式不匹配。
为了解决这个问题，我确保我的 ContentProvider 使用“获取所有”URI 和“通过发布 id 获取”URI 的附加 ID 来调用 notificationChange...这只是一种解决方案。
以这种方式实现有什么缺点吗？事后看来，仅依赖用户在 ContentProvider 查询的选择字符串中设置外键可能会更容易......但像 pierr 一样，我想将其实现为单个 URI。
Not to bring up something old, but I am having trouble implementing this one-to-many relationship as well... If I follow Stefans approach:
What if I later want to add a URI to get a specific comment by id?
The above would create an identical match to the previous URI.
In my case, I tried to resolve this by using
However, this solution can cause problems. For example, if I want to load a cursor using both:
and insert a comment using:
Not all users of the ContentProvider will be notified, as the URI pattern doesn't match.
To solve this, I make sure that my ContentProvider calls notifyChange with the appended ID to BOTH of the 'get all' URI AND the 'get by post id' URI... this is just one solution.
Any drawbacks to implementing it this way? In hindsight it would probably be easier to just rely on the user setting the foreign key in the selection string of the ContentProvider query... but like pierr I wanted to implement it as a single URI.