请求确认：https://google.com/search?query=sea是否属于RestAPI

你的核心判断是对的：这个接口只是HTTP GET方法的常规使用，完全算不上REST API，原因得结合REST的核心约束来拆解：

• 违反资源标识核心原则
  REST要求每个URI对应一个唯一、稳定的资源，但/search?query=sea本质是一个“操作触发入口”，不是资源标识。它的作用是执行搜索并返回动态结果，而非指向某个预先存在、可寻址的实体——换个查询词，URI就变了，而且这个URI的语义是“做搜索”，不是“获取某个特定资源”，完全不符合REST对资源标识的要求。

• 自描述性≠满足统一接口约束
  你提到HTML格式满足自描述性，这点没错（响应带Content-Type: text/html，客户端能解析），但REST的统一接口要求远不止于此：它要求HTTP方法的语义必须严格对应资源的生命周期操作——GET是获取资源，PUT是替换资源，DELETE是删除资源。而这个搜索接口的GET是在“触发一个搜索动作”，不是获取一个稳定存在的资源（每次请求结果可能都不一样），更偏向RPC风格的调用，而非REST的资源操作模式。

• HTML里的链接≠符合HATEOAS要求
  REST的HATEOAS（超媒体作为应用状态引擎）要求：客户端只需要知道一个入口URI，后续所有操作都能通过响应中的超链接引导完成，不需要硬编码任何其他URI。但谷歌搜索结果里的链接是指向外部网页，不是用来引导客户端完成搜索相关的后续操作（比如分页、筛选、修改查询）——你要做下一次搜索，还是得自己拼接?query=xxx，而不是靠响应里的链接跳转，这完全没达到HATEOAS的核心要求。

说白了，REST API必须同时满足所有核心约束（客户端-服务器分离、无状态、缓存、统一接口、分层系统、HATEOAS），哪怕只缺了关键的几条，都不能叫REST API。这个谷歌搜索接口就是普通的Web页面请求，和REST API不沾边。

内容的提问来源于stack exchange，提问作者user18562970