OpenRasta URI 和方法绑定说明 - RESTful Web 服务

发布于 2024-12-05 08:27:52 字数 909 浏览 0 评论 0原文

我正在使用 Openrasta 作为我的 RESTful Web 服务,并且我对方法参数和 URI 有一点疑问,

例如:我遵循了用户实体的设置。

配置:

 ResourceSpace.Has.ResourcesOfType<User>()
          .AtUri("/user")
          .And.AtUri("/user/{userId}")
          .HandledBy<UserHandler>()
          .AsJsonDataContract()
          .And.AsXmlDataContract();

PUT 的处理程序方法:

public OperationResult Put(long userId, User user){}

相同的 URI 将为 http://localhost/User/1

请求正文将为包含如下 JSON:

{
  "userId":1,
  "userName":"FirstName"
}

这里,我的问题是: 使用两个参数定义 PUT 方法是否正确?如果这是正确的方法,那么 PUT 方法中的 userId 参数将包含与 User 实体属性 UserId 相同的值。

并且,在 PUT 方法中,我需要验证这两个值是否相同,如果它们不同,我将返回 BadRequest,指出 URI 与请求中提供的实体不匹配。为什么我们应该明确地执行此操作,为什么不能在处理请求时处理它并让 PUT 方法仅将 User 实体作为参数?我是否遗漏了任何东西,或者我对这个设计的理解完全错误?请问有什么想法或意见吗?

I'm using Openrasta for my RESTful webservice and I've a small doubt with regards to the method parameters and URI

For example: I've following Setup for user entity.

Configuration:

 ResourceSpace.Has.ResourcesOfType<User>()
          .AtUri("/user")
          .And.AtUri("/user/{userId}")
          .HandledBy<UserHandler>()
          .AsJsonDataContract()
          .And.AsXmlDataContract();

Handler method for PUT:

public OperationResult Put(long userId, User user){}

URI for the same will be http://localhost/User/1

Request body will contain a JSON as below:

{
  "userId":1,
  "userName":"FirstName"
}

Here, my question is: Defining the PUT method with two parameters is correct or not? If it is right way to do that, then userId parameter in the PUT method will contain same value as User entity property UserId.

And, in the PUT method I need to verify whether these two values are same or not and if they are not same I return BadRequest stating that URI doesn't match with the entity provided in request. Why should we do this explicitly why not it can be handled while processing the request and have PUT method take only User entity as parameter? Am I missing anything drastically or is my understanding about this design completely wrong? Any thoughts or opinions please?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

锦欢 2024-12-12 08:27:52

有几个原因。

首先,这是一次处理 URI 参数并将其与输入一个变量进行匹配的技术限制。这同样适用于键/值编解码器,因此应该让您拥有一个 User 对象。但是当您使用 json 编解码器时,我们会返回一个完整的对象,因此最终会覆盖 User 。

第二个问题是我从未尝试解决该问题,主要是因为组合 uri 参数和响应主体会导致一大堆隐藏的安全问题,您可能希望远离这些问题。

最后也是同样重要的一点,从建模的角度来看,ReST API 应该使用 URI 作为标识符和链接,而不是外键,因此如果您已经有了标识符(URI),那么就没有理由在实体主体中对其进行建模。

There's a few reasons for it.

First, it's a technical limitation of how URI parameters are processed and matched to inputs one variable at a time. The same gets applied to key/values codecs, so that ought to let you have one User object. but when you use a json codec, we get back a full object, so that would end up overriding User alltogether.

The second one is that I never tried to fix that problem, mostly because combining uri parameters and response bodies leads to a whole bunch of hidden security issues you probably want to stay well clear of.

Last and not least, from a modeling perspective a ReST API ought to use URIs as identifiers and links instead of foreign keys, so if you already have your identifier (the URI), there's little reason why that should be modeled in your entity body.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文