IMHO，您只需在URL中发送JSON编码（即encodeURIComponent），这样就不会违反HTTP规范并将JSON发送到服务器。

如果您尝试利用缓存，可能会遇到问题。代理不会在GET主体中查看参数是否对响应有影响。

您试图实现的目标已经用一种更常见的方法完成了很长时间，这种方法不依赖于在GET中使用有效负载。

您可以简单地构建特定的搜索中介类型，或者如果您希望更具RESTful，可以使用类似OpenSearch的方法，并将请求POST到服务器指示的URI，例如/search。然后，服务器可以生成搜索结果或构建最终URI并使用303重定向。

这具有遵循传统PRG方法的优点，有助于缓存中介缓存结果等。

也就是说，URI无论如何都是针对非ASCII的任何内容进行编码的，application/x-www-form-urlencoded和multipart/form数据也是如此。如果您打算支持ReSTful场景，我建议使用此格式，而不是创建另一种自定义json格式。

创建Requestfactory类

import java.net.URI;

import javax.annotation.PostConstruct;

import org.apache.http.client.methods.HttpEntityEnclosingRequestBase;
import org.apache.http.client.methods.HttpUriRequest;
import org.springframework.http.HttpMethod;
import org.springframework.http.client.HttpComponentsClientHttpRequestFactory;
import org.springframework.stereotype.Component;
import org.springframework.web.client.RestTemplate;

@Component
public class RequestFactory {
    private RestTemplate restTemplate = new RestTemplate();

    @PostConstruct
    public void init() {
        this.restTemplate.setRequestFactory(new HttpComponentsClientHttpRequestWithBodyFactory());
    }

    private static final class HttpComponentsClientHttpRequestWithBodyFactory extends HttpComponentsClientHttpRequestFactory {
        @Override
        protected HttpUriRequest createHttpUriRequest(HttpMethod httpMethod, URI uri) {
            if (httpMethod == HttpMethod.GET) {
                return new HttpGetRequestWithEntity(uri);
            }
            return super.createHttpUriRequest(httpMethod, uri);
        }
    }

    private static final class HttpGetRequestWithEntity extends HttpEntityEnclosingRequestBase {
        public HttpGetRequestWithEntity(final URI uri) {
            super.setURI(uri);
        }

        @Override
        public String getMethod() {
            return HttpMethod.GET.name();
        }
    }

    public RestTemplate getRestTemplate() {
        return restTemplate;
    }
}

和@Autowired，这里是一个带有RequestBody的GET请求示例代码

 @RestController
 @RequestMapping("/v1/API")
public class APIServiceController {
    
    @Autowired
    private RequestFactory requestFactory;
    

    @RequestMapping(method = RequestMethod.GET, path = "/getData")
    public ResponseEntity<APIResponse> getLicenses(@RequestBody APIRequest2 APIRequest){
        APIResponse response = new APIResponse();
        HttpHeaders headers = new HttpHeaders();
        headers.setContentType(MediaType.APPLICATION_JSON);
        Gson gson = new Gson();
        try {
            StringBuilder createPartUrl = new StringBuilder(PART_URL).append(PART_URL2);
            
            HttpEntity<String> entity = new HttpEntity<String>(gson.toJson(APIRequest),headers);
            ResponseEntity<APIResponse> storeViewResponse = requestFactory.getRestTemplate().exchange(createPartUrl.toString(), HttpMethod.GET, entity, APIResponse.class); //.getForObject(createLicenseUrl.toString(), APIResponse.class, entity);
    
            if(storeViewResponse.hasBody()) {
                response = storeViewResponse.getBody();
            }
            return new ResponseEntity<APIResponse>(response, HttpStatus.OK);
        }catch (Exception e) {
            e.printStackTrace();
            return new ResponseEntity<APIResponse>(response, HttpStatus.INTERNAL_SERVER_ERROR);
        }
        
    }
}

得到，用身体！？

在规范方面，你可以，但是，这不是一个好主意，我们将看到这样做是不明智的。

RFC 7231§4.3.1规定身体“没有定义的语义”，但这并不是说它是被禁止的。如果你在请求中附加了一个主体，那么你的服务器/应用程序将从中得到什么，这取决于你。RFC继续声明GET可以是“各种数据库记录的编程视图”。显然，这样的视图多次由大量输入参数定制，这些参数放在请求目标的查询组件中并不总是方便甚至安全的。

好的：我喜欢冗长的辞藻。很明显，读取/获取资源不会对服务器产生任何可观察到的副作用（该方法是“安全的”），并且无论第一个请求的结果如何，都可以以相同的预期效果重复请求（该方法“幂等”）。

糟糕的是：HTTP/1.1的早期草案禁止GET具有主体，而且据称，某些实现直到今天都会丢弃主体、忽略主体或拒绝消息。例如，哑HTTP缓存可能只从请求目标构建缓存密钥，而忽略了主体的存在或内容。更愚蠢的服务器可能会如此无知，以至于将主体视为一个新的请求，这实际上被称为“请求走私”（这是将“请求发送到一个设备，而另一个设备不知道它”的行为-源）。

由于我认为主要关注的是实现之间的不可操作性，正在进行的工作建议将GET主体分类为“不应该”，“除非（请求）直接发送给一个源服务器，该服务器先前已在带内或带外表示此类请求有目的，并且将得到充分支持”（我的重点）。

解决方法：对于这种方法的一些问题，可以使用一些技巧。例如，不知道主体的缓存可以通过简单地将从主体派生的哈希附加到查询组件来间接地变得知道主体，或者通过响应缓存控制（没有来自服务器的缓存头）来完全禁用缓存。

唉，当涉及到请求链时，人们往往无法控制——甚至无法意识到所有当前和未来的HTTP中介以及它们将如何处理GET主体。这就是为什么这种方法通常被认为是不可靠的。

但是POST不是幂等的！

POST是一种替代方法。POST请求通常包括一个消息体（仅用于记录，正文不是要求，请参阅RFC 7230§3.3.2）。RFC 7231（§4.3.3）中的第一个用例示例是“向数据处理过程提供数据块[…]”。所以，就像GET与身体一样，身体在后端发生什么取决于你。

好处：当您希望出于任何目的发送请求体时，也许可以采用一种更常见的方法，这样可能会从您的团队成员中产生最少的噪音（有些人可能仍然错误地认为POST必须创建资源）。

此外，我们经常向其传递参数的是一个对不断变化的数据进行操作的搜索函数，只有在响应中提供明确的新鲜度信息时，POST响应才可缓存。

糟糕的是：POST请求没有被定义为幂等，导致请求重试犹豫。例如，在页面重新加载时，浏览器不愿意重新提交HTML表单，而不会向用户提示不可读取的隐藏消息。

解决方法：好吧，POST没有被定义为幂等并不意味着它不一定是幂等的。事实上，RFC 7230§6.3.1写道：“知道（通过设计或配置）对给定资源的POST请求是安全的用户代理可以自动重复该请求”。因此，除非您的客户端是HTML表单，否则这可能不是真正的问题。

QUERY是圣杯

有人提出了一种新的方法QUERY，它确实定义了消息体的语义，并将该方法定义为幂等。看看这个。

编辑：顺便说一句，我在发现了一个代码库后，无意中遇到了这个StackOverflow问题，在该代码库中，他们只将PUT请求用于服务器端搜索功能。这是他们的想法，包括一个带参数的体，并且也是幂等的。遗憾的是，PUT的问题在于请求体具有非常精确的语义。具体来说，PUT“请求创建目标资源的状态或将其替换为[正文]中的状态”（RFC 7231§4.3.4）。显然，这排除了PUT作为一个可行的选项。

不符合base64编码的标头怎么办？“某些参数：sdfSD45fdg45/aS”

长度限制hm.你不能让POST处理区分含义吗？如果你想要像排序这样的简单参数，我不明白为什么这会是一个问题。我想你肯定担心。