• 协议约定问题


    RESTful 可不仅仅是指 API,而是一种架构风格,全称 Representational State Transfer,表述性状态转移

    所谓的无状态,其实是服务端维护资源的状态,客户端维护会话的状态。对于服务端来讲,只有资源的状态改变了,客户端才调用 POST、PUT、DELETE 方法来找我;如果资源的状态没变,只是客户端的状态变了,就不用告诉我了,对于我来说都是统一的 GET。

    虽然这只改进了 GET,但是已经带来了很大的进步。因为对于互联网应用,大多数是读多写少的。而且只要服务端的资源状态不变,就给了我们缓存的可能。例如可以将状态缓存到接入层,甚至缓存到 CDN 的边缘节点,这都是资源状态不变的好处。

    按照这种思路,对于 API 的设计,就慢慢变成了以资源为核心,而非以过程为核心。也就是说,客户端只要告诉服务端你想让资源状态最终变成什么样就可以了,而不用告诉我过程,不用告诉我动作。

    对于 RESTful API 来讲,传输协议——基于 HTTP,协议约定——基于 JSON,最后要解决的是服务发现问题。

    Eureka 是用来实现注册中心的,负责维护注册的服务列表。服务分服务提供方,它向 Eureka 做服务注册、续约和下线等操作,注册的主要数据包括服务名、机器 IP、端口号、域名等等。

    另外一方是服务消费方,向 Eureka 获取服务提供方的注册信息。为了实现负载均衡和容错,服务提供方可以注册多个。

    当消费方要调用服务的时候,会从注册中心读出多个服务来,那怎么调用呢?当然是 RESTful 方式了。

    Spring Cloud 提供一个 RestTemplate 工具,用于将请求对象转换为 JSON,并发起 Rest 调用,RestTemplate 的调用也是分 POST、PUT、GET、  DELETE 的,当结果返回的时候,根据返回的 JSON 解析成对象。

    通过这样封装,调用起来也很方便。

    此文章为10月Day4学习笔记,内容来源于极客时间《趣谈网络协议》,推荐该课程。

  • 相关阅读:
    Qt 之元对象
    springmvc-day01
    如何从800万数据中快速捞出自己想要的数据?
    谷歌(edge)浏览器过滤,只查看后端发送的请求
    【C++风云录】精益求精:探索C++开发中的性能优化艺术
    libevent库event事件使用
    Flink报错could not be loaded due to a linkage failure
    macOS查端口占用进程
    ASP.NET Core Web API 流式返回,逐字显示
    docker install consul
  • 原文地址:https://blog.csdn.net/key_3_feng/article/details/133458235