看到这个标题，你肯定觉得离谱。怎么会有公司规定所有接口都用Post，是架构菜还是开发菜。这可不是夸大其词，这样的公司不少。

在特定的情况下，规定使用Post可以减少不少的麻烦，一起看看。

什么是Restful WebService

当谈到 RESTful Web 服务时，它指的是一种基于 REST（Representational State Transfer）原则设计的 Web 服务架构风格。REST 是一种用于构建可伸缩、可维护和可扩展的分布式系统的设计原则。RESTful Web 服务提供了一种在不同计算机系统之间进行通信的方式，使得这些系统能够使用标准的 HTTP 方法（例如 GET、POST、PUT、DELETE）进行交互。

以下是 RESTful Web 服务的一些关键概念和原则：

1. 资源（Resources）：在 RESTful 架构中，所有的数据都被视为资源。每个资源都有一个唯一的标识符（通常是 URI）用于访问它。例如，一个博客应用可能有一个博客文章资源，其 URI 可能是 /articles/123。
2. 表示（Representation）：资源可以以不同的形式进行表示，例如 JSON、XML 或者 HTML。客户端可以通过请求头中的 Accept 字段指定所期望的表示形式。服务器将根据客户端的要求返回相应的表示形式。
3. 状态转移（State Transfer）：客户端通过发送包含资源状态的请求来与服务器进行交互。服务器会根据请求中的状态进行相应的处理，并返回相应的结果。常用的 HTTP 方法用于表示状态转移，例如 GET 用于获取资源，POST 用于创建资源，PUT 用于更新资源，DELETE 用于删除资源。
4. 统一接口（Uniform Interface）：RESTful Web 服务应该具有统一的接口，这意味着使用标准的 HTTP 方法和状态码来进行通信，并遵循一致的约定。这样可以使得客户端和服务器之间的交互更加简单和可预测。
5. 无状态（Stateless）：RESTful Web 服务是无状态的，这意味着服务器不会保存客户端的状态信息。每个请求都应该包含足够的信息来完成处理，服务器不需要依赖之前的请求。

通过遵循这些原则，RESTful Web 服务提供了一种轻量级、可扩展和易于集成的方式来构建分布式系统。它在互联网上得到了广泛的应用，许多现代的 Web API 都采用了 RESTful 设计风格。开发人员可以使用各种编程语言和框架来实现 RESTful Web 服务，例如使用 Java 的 Spring Boot、Python 的 Flask 或者 Node.js 的 Express 等。

严格遵守Restful可能带来的问题

严格遵守 RESTful 风格可能会带来一些挑战和问题。虽然 RESTful 风格是一种广泛采用的架构设计原则，但在实践中，完全遵循 RESTful 风格可能会遇到以下问题：

1. 版本控制：RESTful 风格鼓励使用统一的资源标识符（URI）来表示资源，而不是使用特定的操作动词。这意味着对于同一资源的不同版本或不同操作的支持，需要考虑如何在 URI 中进行适当的版本控制。
2. 复杂性：严格遵循 RESTful 风格可能导致接口设计变得复杂。为了实现一些复杂的业务需求，可能需要引入嵌套资源、自定义动作等，这可能会导致 URI 结构变得复杂且难以维护。
3. 性能和效率：RESTful 风格鼓励无状态的交互，不保留客户端的状态信息。这在某些场景下可能导致一些性能和效率的问题，例如需要频繁进行身份验证和授权的情况。
4. 安全性：RESTful 风格的安全性依赖于使用正确的 HTTP 方法、状态码和身份验证等。在设计和实现过程中，需要特别注意安全性的考虑，以保护资源和防止潜在的安全漏洞。
5. 兼容性和标准化：尽管 RESTful 风格是一个通用的设计原则，但在不同的实现和框架中，对于某些细节的实现可能会有差异。这可能导致在不同系统之间进行集成时出现兼容性和标准化的问题。

尽管严格遵守 RESTful 风格可能会带来一些挑战，但在大多数情况下，RESTful 风格仍然是一种非常有用的架构设计原则，可以帮助构建可伸缩、可维护和可扩展的分布式系统。在实践中，根据具体的需求和业务场景，适当地调整和灵活应用 RESTful 原则是很常见的做法。

有些公司可能规定所有接口都使用 POST 方法，这可能是由于他们的特定需求、安全性考虑或历史原因等。以下是一些常见的原因：

1. 统一风格和规范：通过要求所有接口都使用 POST 方法，可以确保接口在风格和规范上保持一致。这样可以使开发人员更容易理解和维护接口，减少混乱和错误的发生。
2. 安全性考虑：POST 方法对请求的数据进行封装，将数据放在请求体中，而不是通过 URL 参数传递。这可以防止敏感数据被明文传输并暴露在 URL 中。对于包含敏感信息的请求，使用 POST 方法可以提供额外的安全性。
3. 防止缓存和日志泄露：GET 方法的请求参数通常会被缓存或记录在服务器的日志中，这可能导致敏感信息泄露的风险。使用 POST 方法可以减少这种风险，因为请求参数不会在 URL 中可见，也不会被默认缓存或记录。
4. 复杂数据传输：有时候，接口需要传输复杂的数据结构或大量的参数。使用 POST 方法可以将数据放在请求体中以更灵活和结构化的方式进行传输。
5. 隐藏业务逻辑：使用 POST 方法可以隐藏服务器端的业务逻辑，因为请求参数不会在 URL 中暴露。这样可以增加接口的安全性和保护服务器端的实现细节。

团队技术水平与规范问题

我们都知道，get请求一般用来获取服务器信息，post一般用来更新信息。get请求能做的，post都能做，get请求不能做的，post也都能做。如果你的团队都是大佬，或者有着良好的团队规范，所有人都在平均水平线之上，并且有良好的纠错机制，那基本不会制定这样的规则。

但如果团队成员水平参差不齐，尤其是小团队，创业团队，常常上来就开干，没什么规范，纯靠开发者个人素质决定代码质量，这样的团队就不得不制定这样的规范。

毕竟可以减少非常多的问题，Post不用担心URL长度限制，也不会误用缓存。通过一个规则减少了出错的可能，这个决策性价比极高。

造成的结果：公司有新人进来，什么lj公司，还有这种要求，回去就在群里讲段子。

实际上都是有原因的。有些外包公司或者提供第三方接口的公司也会选择只用Post，就是图个方便。

Feign调用中不直接支持PUT与DELETE等问题

实际上，Feign 在默认情况下确实不直接支持 PUT 方法。Feign 是一个声明式的 HTTP 客户端，旨在简化微服务之间的通信。它使用注解方式定义接口，并自动生成实现该接口的代理类。在 Feign 的设计中，默认只支持 GET 和 POST 方法。

然而，您仍然可以通过一些方式在 Feign 中实现对 PUT 方法的支持：

1. 使用 @RequestMapping 注解：可以在 Feign 接口的方法上使用 @RequestMapping 注解，并将请求方法设置为 PUT。这样 Feign 将会生成相应的 PUT 请求。

javaCopy code@FeignClient(name = "example")
public interface ExampleClient {

    @RequestMapping(method = RequestMethod.PUT, value = "/resource")
    void updateResource(Resource resource);
}

2. 自定义 Feign 配置：您可以为 Feign 创建自定义的配置类，并使用 RequestInterceptor 自定义请求。通过创建一个 RequestInterceptor，您可以修改请求的方法为 PUT，并相应地处理请求。

javaCopy code@Configuration
public class FeignConfiguration {

    @Bean
    public RequestInterceptor putRequestInterceptor() {
        return template -> template.method(HttpMethod.PUT);
    }
}

然后，将自定义的配置类与 Feign 接口进行关联：

javaCopy code@FeignClient(name = "example", configuration = FeignConfiguration.class)
public interface ExampleClient {

    @RequestMapping(method = RequestMethod.POST, value = "/resource")
    void updateResource(Resource resource);
}

通过这些方法，您可以在使用 Feign 进行微服务之间的通信时，实现对 PUT 方法的支持。请注意，这些方法可能因 Feign 版本和配置方式而略有不同，因此请根据您使用的 Feign 版本和具体需求进行适当的调整。

**实践

以下是使用 RESTful Web 服务的一些**实践：

1. 使用合适的 HTTP 方法：根据资源的操作类型选择适当的 HTTP 方法。GET 用于获取资源，POST 用于创建资源，PUT 用于更新资源，DELETE 用于删除资源。
2. 使用合适的状态码：根据操作的结果，返回合适的 HTTP 状态码。例如，200 表示成功，201 表示资源创建成功，204 表示成功但没有响应内容，400 表示客户端错误，500 表示服务器错误等。
3. 使用恰当的资源命名：为资源选择有意义的命名，使用名词而不是动词作为资源的标识符。资源的 URL 应该反映其层次结构和关系，遵循 RESTful URL 的规范。
4. 使用合适的数据格式：根据需要，选择合适的数据格式，如 JSON 或 XML。JSON 是最常用的格式，因为它轻量、易读和易解析。
5. 使用版本控制：如果需要对接口进行版本控制，可以在 URL 或请求头中添加版本信息，以确保不同版本的兼容性和演进性。
6. 使用 HATEOAS：Hypermedia As The Engine Of Application State (HATEOAS) 是一种设计原则，它通过在响应中提供链接来表达资源之间的关系。使用 HATEOAS 可以使客户端更好地理解和导航 API。
7. 安全性和身份验证：确保对敏感操作和资源进行适当的身份验证和授权。使用安全标准和协议（如 HTTPS、OAuth 等）来保护数据传输和访问。
8. 错误处理和异常管理：定义合适的错误响应结构，并提供有用的错误信息和适当的错误码。使用异常处理机制来捕获和处理异常情况，并返回相应的错误响应。
9. 缓存和性能优化：使用适当的缓存策略来减少服务器负载和提高性能。合理利用缓存机制，使用合适的缓存标头（如 Cache-Control、ETag 等）。
10. API 文档和规范：编写清晰、详细的 API 文档，包括资源的结构、操作和使用方法。使用工具（如 Swagger、OpenAPI 等）来生成和管理 API 文档。

在平时开发中，您可以按照这些**实践来设计和实现 RESTful Web 服务：

• 根据业务需求和资源类型，选择合适的 HTTP 方法（GET、POST、PUT、DELETE）来定义接口操作。
• 使用合适的 URL 结构和资源命名规范，反映资源的层次结构和关系。
• 根据需要，使用合适的数据格式（如 JSON）进行数据交换。
• 使用合适的状态码

尽管有这些原因，选择使用 POST 方法作为唯一的 HTTP 方法并不是通用的**实践。在设计 RESTful Web 服务时，应根据具体的需求和接口的语义性选择适当的 HTTP 方法。根据不同的操作类型，合理地使用 GET、POST、PUT 和 DELETE 方法可以使接口更加直观、可预测和符合 RESTful 原则。