我正在为我们的应用程序开发一个新的RESTful Web服务。

当对某些实体执行GET时,客户端可以请求实体的内容。如果他们想添加一些参数(例如排序列表),可以在查询字符串中添加这些参数。

或者,我希望人们能够在请求主体中指定这些参数。HTTP/1.1似乎并没有明确禁止这一点。这将允许他们指定更多信息,可能会更容易指定复杂的XML请求。

我的问题:

这完全是个好主意吗?HTTP客户端在GET请求中使用请求体时会遇到问题吗?

https://www.rfc-editor.org/rfc/rfc2616


当前回答

创建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,也可以发送POST,然后放弃RESTish宗教信仰(这并不是很糟糕,5年前只有一个信仰的成员——他在上面的评论)。

这两个都不是很好的决定,但发送GET主体可能会防止某些客户端和某些服务器出现问题。

进行POST可能会遇到一些RESTish框架的障碍。

Julian Reschke在上文中建议使用非标准HTTP头,如“SEARCH”,这可能是一个很好的解决方案,只是它不太可能被支持。

列出能够和不能做到上述每一项的客户可能是最有成效的。

无法发送带有正文的GET的客户端(我知道):

XmlHTTPRequest Fiddler

可以发送带有正文的GET的客户端:

大多数浏览器

可以从GET检索正文的服务器和库:

阿帕奇PHP文件

从GET中剥离主体的服务器(和代理):

?

我不建议这样做,这违背了标准做法,也没有提供那么多回报。您希望保留内容的正文,而不是选项。

restclient和REST控制台都不支持这一点,但curl支持。

HTTP规范在第4.3节中说明

如果请求方法规范(第5.1.1节)不允许在请求中发送实体体,则请求中不得包含消息体。

第5.1.1节将我们重定向到第9.x节以了解各种方法。它们都没有明确禁止包含消息体。然而

第5.2节规定

通过检查请求URI和主机头字段来确定由Internet请求标识的确切资源。

第9.3节规定

GET方法意味着检索请求URI标识的任何信息(以实体的形式)。

这一起表明,在处理GET请求时,服务器不需要检查除请求URI和主机头字段之外的任何内容。

总之,HTTP规范不会阻止您使用GET发送消息体,但存在足够的歧义,如果不是所有服务器都支持它,我不会感到惊讶。

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

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