【问题标题】:Can I use TCP in a RESTful service?我可以在 RESTful 服务中使用 TCP 吗?
【发布时间】:2012-12-26 09:11:29
【问题描述】:

REST 正在使用 Web 的当前功能并在其上应用一些原则以提高效率。它使用标准的 HTTP 动词进行通信,并利用其无状态特性。

但是,REST 服务是否可以使用 TCP 协议进行通信?如果是,那么它会违反其原则吗?

【问题讨论】:

  • 我从未听说过 REST 的“原则”是为了提高效率。

标签: c# .net wcf rest


【解决方案1】:

HTTP 是基于 TCP/IP 的协议。因此,当您使用 REST 时,您已经在使用 TCP 进行通信。但是,如果您想在纯 TCP 套接字上使用 REST,而不使用 HTTP,那么不,这没有意义,因为 REST 基于 HTTP 动词和标头。这些概念只存在于 HTTP 协议中。

【讨论】:

  • 您只能将 REST 与 HTTP 一起使用。
  • REST完全依赖HTTP是真的吗?
  • @MBen 是的,完全正确。
  • @GameScripting 我是 REST 和 HTTP 的新手,但我读到 REST 独立于 HTTP,碰巧 HTTP 符合或很好地符合 REST 要求:-)
  • @MBen 理论上你是对的。 REST 只是一个关于如何访问资源的想法。实际上,它仅与 HTTP 一起使用。如果有人在谈论 REST,那么他/她肯定在谈论 HTTP。
【解决方案2】:

REST 是一种架构风格(或一组约束)。碰巧 HTTP 可以轻松匹配所有这些约束。除此之外,还有很多 HTTP/1.1 基础设施已经支持它:服务器、代理、缓存、客户端库、解析器等。像这样的东西:

是否可以从头开始构建 RESTful 且不依赖 HTTP 的系统?当然。来自话题权威Roy Fielding himself

REST API 不应依赖于任何单一的通信协议。

如果您阅读了这篇文章,或者实际上是 Roy's dissertation,您会意识到,如果您尝试遵循所有限制,您最终会得到一些看起来和行为与现代 HTTP 非常相似的东西,尽管它可能缺少大部分HTTP 具有的基础架构支持。因此,问题是:值得吗?

此外,如果您查看大多数 RESTful 服务,它们很少是完全 REST 服务。这就是为什么他们称自己为“RESTful 服务”,而不是“REST 服务”。顺便说一句,该站点的 API 非常接近于完整的 REST 实现。

【讨论】:

    【解决方案3】:

    但是,REST 服务是否可以使用 TCP 协议进行通信?如果是,那会不会违反它的原则?

    简答

    不,如果您根据 REST 原则编写它,它不会违反其原则。是的,如果您不遵循 REST 原则,它将违反其原则。您在客户端和服务器端的代码必须遵守 REST 规则。例如,如果我向“...employee/22”发送“GET”,最好向我发送 REST 响应,例如200,标头和内容类型等。所有这些基本上都在做 HTTP 所做的。


    长答案

    @ГеоргиКременлиев 提供了您问题的答案。我实际上认为这可能是唯一正确的答案。

    确实,REST 主要与 HTTP 相关联,当人们谈论 REST 时,他们指的是 HTTP。但是,“大部分”并不意味着“总是”,即使它是“总是”,也不意味着没有 HTTP 就不可能实现 REST,@ГеоргиКременлиев 答案的链接中指出了这一点。 HTTP 运行良好(客户端和服务器),采用这些原则来创建具有这些原则的任何客户端/服务器应用程序,因此它们可以享受与 HTTP 相同的好处。换句话说,

    1. 任何客户端都可以设计为理解 REST(例如,浏览器理解 REST)
    2. 任何服务器都可以设计为理解 REST(例如,Web 服务器理解 REST)

    这里有一点很重要,REST 原则是从 HTTP 借来的。因此,如果您是 RESTful,则意味着您遵循 HTTP 原则。

    话虽如此,如果您不想使用 HTTP,那么您的客户端和/或服务器都必须理解 HTTP 所说的相同语言。例如,它使用 GET、POST、PUT 等动词和 200、300、400 等响应代码。因此,您的服务器需要了解如何响应 ...employee/22 等请求并返回:

    • 200 OK,301 永久移动,500 等等...
    • 内容类型
    • 需要其他标题

    您的客户端还需要了解这些标头才能向服务器发送请求并使用来自服务器的响应。

    如果你确实实现了所有这些、安全性(身份验证和授权等)、chaching 和列表继续,你会意识到你只是在尝试重新发明轮子:HTTP。

    值得吗?您确定性能瓶颈是 HTTP 协议还是您的后端代码、对数据库的查询等?

    【讨论】:

      【解决方案4】:

      角度略有不同:

      1 .不要使用 WCF 创建基于 REST 的服务。使用 Asp.Net WebAPI。

      2 。只是为了好玩:如果您想使用带有“REST”原则的 WCF TCP 绑定,也许您可​​以创建一个基于“资源”的无状态 API,而不是像一个典型的 RPC。

      [ServiceContract]
      interface RestApi
      {
          Result Get(string id);
          Result Post(string id, Resource resource);
          Result Put(string id, Resource resource);
          void Delete(string id);
      }
      

      这样您就不必为每项服务定义不同的合同,只需针对不同的交互调整您的资源。

      注意:我不建议任何人这样做:这是在重新发明轮子。如果需要 REST,请使用 WebAPI。

      【讨论】:

      • 您可以在 WCF 中完全创建基于 REST 的服务,它们甚至具有诸如 WebGet 之类的属性来实现该目的。这个答案不是事实,而是固执己见。
      【解决方案5】:

      正如 Darin 已经answered,HTTP 是一个 TCP 协议,它有一些开销,这正是 RESTful 定义中使用的。所以,不,你不能消除 HTTP 开销。

      我相信您的问题“我可以将 TCP 用于更快的 RESTful 应用程序吗?”与问题“如果 HTTP 比纯 TCP 慢,为什么这么多网站使用 REST ?”。

      事实是:HTTP 确实比纯二进制 TCP 形式慢,但是在大多数应用程序中,您的用户不会注意到差异,因为开销确实非常大很小,通常客户端每分钟只会发出几个请求。

      例如:GET /posts?userId=5

      如果这个请求的完成时间超过几毫秒,那么问题不在于 HTTP 协议。性能问题与网络延迟、服务器端代码或从数据库中检索数据的方式有关。

      【讨论】:

        【解决方案6】:

        您不能将 Http 之外的其他绑定用于基于 Rest 的服务。这是因为 Rest 是一种基于一定原则的建筑风格。其中一个原则是借助 web 的无状态协议 http,同时它也希望使用 TCP 协议中不可用的 Http 字词,例如 Get、Port、Put 和 Delete

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多