我们有一个API,它期望我们自己的特定于供应商的内容类型,例如application/vnd.xxxx.custom.custom-data+json,但是从REST.Client的源代码来看,似乎总是默认为REST.Types中的某个ContentTypes,例如,当在我的主体请求中分配ctNone时,它将默认为ctAPPLICATION_X_WWW_FORM_URLENCODED。
我尝试将内容类型直接分配给TRESTClient.ContentType属性,但这会被TRESTRequest.ContentType值覆盖。我还在TRESTRequest上添加了自定义内容类型作为参数,它确实得到了识别,但仍然在末尾追加ctAPPLICATION_X_WWW_FORM_URLENCODED,导致无效的mime类型异常。
begin
APIClient := TRESTClient.Create(API_URL);
APIRequest := TRESTRequest.Create(nil);
try
JsonToSend := TStringStream.Create(strJson, TEncoding.UTF8);
APIClient.Accept := 'application/vnd.xxxx.custom.custom-data+json';
// Below line gets overwritten
APIClient.ContentType := 'application/vnd.xxxx.custom.custom-data+json';
APIRequest.Client := APIClient;
APIRequest.Resource := 'ENDPOINT_URL';
APIRequest.Accept := 'application/vnd.xxxx.custom.custom-data+json';
APIRequest.AddParameter(
'Content-Type',
'application/vnd.xxxx.custom.custom-data+json',
pkHTTPHEADER,
[poDoNotEncode]
); // This includes the custom CT in the request but appends the preset one as well so in this case ctAPPLICATION_X_WWW_FORM_URLENCODED when ctNone is set
APIRequest.AddBody(JsonToSend, ctNone);
APIRequest.Method := rmPost;
try
APIRequest.Execute;
except
on E: Exception do
ShowMessage('Error on request: '#13#10 + e.Message);
end;
finally
JsonToSend.Free;
end;
end;在我看来,如果在标头参数中提供了一个内容类型,那么它将使用指定的参数,而不是任何预置参数。但是,会引发API异常,因为提供了未知的媒体类型。API异常如下:
Invalid mime type "application/vnd.xxxx.custom.custom-data+json, application/x-www-form-urlencoded": Invalid token character ',' in token "vnd.xxxx.custom.custom-data+json, application/x-www-form-urlencoded"我的理解是,它正在识别我在params中提供的自定义内容类型,但仍然在请求头中添加来自REST.Types的预置内容类型之一,导致它失败。我希望它能够发送请求头为application/vnd.xxxx.custom.custom-data+json (不包括application/x-www-form-urlencoded )的主体。
发布于 2019-06-03 20:33:10
显然,TRestCLient试图在您的场景中表现得太聪明。然而,有一个正常的方法绕过这一点。关键是:
ctNone、ctMULTIPART_FORM_DATA或ctAPPLICATION_X_WWW_FORM_URLENCODED的单一内容,请执行以下操作。Content-Type,请执行以下操作。样本代码:
uses
System.NetConsts;
RESTClient1.BaseURL := 'https://postman-echo.com/post';
RESTRequest1.Method := rmPOST;
RESTRequest1.Body.Add('{ "some": "data" }', ctAPPLICATION_JSON);
RESTRequest1.AddParameter(sContentType, 'application/vnd.hmlr.corres.corres-data+json',
pkHTTPHEADER, [poDoNotEncode]);
RESTRequest1.Execute;回波服务的响应是:
{
"args":{
},
"data":{
"some":"data"
},
"files":{
},
"form":{
},
"headers":{
"x-forwarded-proto":"https",
"host":"postman-echo.com",
"content-length":"18",
"accept":"application/json, text/plain; q=0.9, text/html;q=0.8,",
"accept-charset":"UTF-8, *;q=0.8",
"content-type":"application/vnd.hmlr.corres.corres-data+json",
"user-agent":"Embarcadero RESTClient/1.0",
"x-forwarded-port":"443"
},
"json":{
"some":"data"
},
"url":"https://postman-echo.com/post"
}当然,要注意回显头,特别是Content-Type。我在Delphi10.2东京测试了这个示例,所以希望它也能在XE8中工作。
编辑
你观察到的行为是一个bug (RSP-14001),它是固定在RAD工作室10.2东京。
解决这一问题的方法有多种。举几个例子:
TNetHttpClient,如果您可以放弃TRestClient提供的所有其他好处的话。TRestClient实现细节。破解它的最简单方法是修补方法TCustomRESTRequest.ContentType (注意,如果参数的AParamsArray参数包含单一的pkREQUESTBODY参数,则返回参数的不变量)。这将允许我们向ctNone类型的请求添加主体,这样修补的方法也将返回ctNone,这将有效地防止将另一个值附加到Content-Type头。
另一种选择是修补方法TRESTHTTP.PrepareRequest,以便在推断请求的内容类型之前更倾向于自定义Content-Type头。这是BTW在RADStudio10.2东京修正后,当前的实现是如何工作的。此逻辑还应用于其他标头- Accept、Accept-Charset、Accept-Encoding、User-Agent。修补方法TRESTHTTP.PrepareRequest稍难实现,因为它具有private可见性。
最难的选项是修补TWinHTTPRequest.SetHeaderValue以丢弃次要内容类型值。这也是最危险的,因为它会对应用程序中与HTTP相关的任何东西(依赖于THTTPClient)产生影响。修补类也很困难,尽管不是不可能,因为它完全隐藏在implementation部分的System.Net.HttpClient.Win.pas中。这是一个巨大的遗憾,因为它也阻止您创建自定义子类。也许有一个很好的理由。(谁知道;)
https://stackoverflow.com/questions/56430564
复制相似问题