简体   繁体   English

ServiceStack JsonServiceClient 请求不一致

[英]ServiceStack JsonServiceClient Requests not consistent

I've created a ServiceStack.JsonServiceClient to consume 3rd party API.我创建了一个ServiceStack.JsonServiceClient来使用第 3 方 API。

I'm using the Get(IReturn<MyType>) method.我正在使用Get(IReturn<MyType>)方法。

My Request object looks like this:我的请求 object 看起来像这样:

public class MyRequest : Base, IReturn<MyType>
{
    public MyRequest(DateTime dateTime)
    {
        Date = dateTime.Date;
    }

    [DataMember(Name = "date")]
    public DateTime Date { get; init; }
}

And normally everything is fine but sometimes it fails to get results.通常一切都很好,但有时无法获得结果。

I set ServiceStack.JsonServiceClient.CaptureHttp() and reviewed the logs and what I found was that it's failing when Date is converted to a long rather than a string in this format yyyy-MM-dd .我设置了ServiceStack.JsonServiceClient.CaptureHttp()并查看了日志,我发现当Date转换为long而不是这种格式的string时它失败了yyyy-MM-dd

I'm thinking it's probably my fault.我想这可能是我的错。 I probably set a static setting that toggles this behavior somewhere in my solution but I don't remember and I'm not finding it.我可能设置了一个 static 设置,该设置在我的解决方案中的某处切换此行为,但我不记得了,也没有找到它。

My question is really just why is this happening.我的问题是为什么会发生这种情况。

I already have a solution and that is to modify MyRequest slightly as follows:我已经有一个解决方案,那就是稍微修改MyRequest如下:

public class MyRequest : Base, IReturn<MyType>
{
    public MyRequest(DateTime dateTime)
    {
        Date = $"{dateTime.Date:yyyy-MM-dd}";
    }

    [DataMember(Name = "date")]
    public string Date { get; init; }
}

but again, why was this required and what could possibly be causing it to work for some time and then change behavior.但同样,为什么需要这样做以及可能导致它工作一段时间然后改变行为的原因。

As per Date Serialization the ServiceStack's Serializers return Date's in WCF's Date serialization format, here's some parsing examples .根据日期序列化,ServiceStack 的序列化程序以 WCF 的日期序列化格式返回日期,这里有一些解析示例 You can also configure it to use a different Date format , eg:您还可以将其配置为使用不同的日期格式,例如:

JsConfig.Init(new Config {
    DateHandler = DateHandler.ISO8601,
});

Please note you should never put any implementation logic inside DTOs, they should be impl-free classes used as inert Data Transfer Objects (DTO) only.请注意,您永远不应该在 DTO 中放置任何实现逻辑,它们应该是仅用作惰性数据传输对象 (DTO) 的无实现类。

All DTOs should also have a parameterless constructor which are used by serializers to rehydrate DTOs during deserialization.所有 DTO 还应该有一个无参数的构造函数,序列化程序使用该构造函数在反序列化期间重新水化 DTO。

If you want to add impl logic in a class put it in a separate domain model that you map to a plain DTO that is returned from your API instead. If you want to add impl logic in a class put it in a separate domain model that you map to a plain DTO that is returned from your API instead.

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 ServiceStack JsonServiceClient 响应头 - ServiceStack JsonServiceClient Response Header 在ServiceStack JsonServiceClient上设置Accept标头 - Set Accept header on ServiceStack JsonServiceClient ServiceStack.JsonServiceClient.HttpLog 未填充 - ServiceStack.JsonServiceClient.HttpLog is not populating 反序列化时,ServiceStack JsonServiceClient静默失败 - ServiceStack JsonServiceClient Silently Failing When Deserializing ServiceStack JsonServiceClient,强制为localhost线路上的流量? - ServiceStack JsonServiceClient, force traffic on the wire for localhost? ServiceStack JsonServiceClient使用路由属性发送会引发未找到异常 - ServiceStack JsonServiceClient Send using route attributes throws exception not found 类型&#39;ServiceStack.JsonServiceClient&#39;中的方法&#39;Get&#39;…没有实现 - Method 'Get' in type 'ServiceStack.JsonServiceClient' … does not have an implementation 提取数据时,ServiceStack MsgPackServiceClient失败,但JsonServiceClient起作用 - ServiceStack MsgPackServiceClient fails when fetching data but JsonServiceClient works 什么是在Servicestack JsonServiceClient Get方法上实现重试的最佳解决方案? - Whats the best solution to implement retry on Servicestack JsonServiceClient Get method? ServiceStack:如何从JsonServiceClient的Get方法获取StatusCode - ServiceStack :How to get StatusCode from JsonServiceClient Get method
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM