REST作为协议不支持OOP，Get方法就是证明。作为解决方案，您可以将DTO序列化为JSON，然后创建查询字符串。在服务器端，您将能够将查询字符串反序列化为DTO。

看看：

ServiceStack中基于消息的设计使用WCF构建基于RESTful消息的Web服务

基于消息的方法可以帮助您解决Get方法的限制。您可以将任何DTO作为请求主体发送

Nelibur web服务框架提供了您可以使用的功能

var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
    {
        Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
    };
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

根据RFC 2616第4.3节“消息正文”：

服务器应读取并转发任何请求的消息体；如果请求方法不包括实体实体的定义语义，则在处理请求时应忽略消息体。

也就是说，服务器应该始终从网络中读取任何提供的请求体（检查内容长度或读取分块体等）。此外，代理应该转发他们收到的任何此类请求。然后，如果RFC为给定方法的主体定义了语义，那么服务器实际上可以使用请求主体来生成响应。然而，如果RFC没有定义主体的语义，那么服务器应该忽略它。

这与上面Fielding的引用一致。

第9.3节“GET”描述了GET方法的语义，没有提到请求体。因此，服务器应该忽略它在GET请求中收到的任何请求体。

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

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

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

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

得到，用身体！？

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

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作为一个可行的选项。

创建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);
        }
        
    }
}

您有一个选项列表，这些选项比使用GET请求体要好得多。

假设每个类别都有类别和项目。两者都由id标识（在本例中为“catid”/“itemid”）。您希望按照特定“顺序”中的另一个参数“sortby”进行排序。您希望传递“sortby”和“order”的参数：

你可以：

使用查询字符串，例如。example.com/category/{catid}/item/{itemid}？sortby=itemname&order=asc对路径使用mod_rewrite（或类似）：示例.com/category/{catid}/item/{itemid}/{sortby}/{order}使用随请求传递的单个HTTP标头使用其他方法（例如POST）检索资源。

所有这些都有其缺点，但都比使用GET和身体要好得多。