0

I tried integration with the API of my partner, but the response from API has the value of date as an array of integers like [2014, 3, 10]. The C# class generated from OpenAPI for this field is DateTimeOffset. So, an error occurs when parsing the response to object DTO.

Response example: `

{
  "id": "4535e63b-ab8f-11e3-bd14-180373e16dda",
  "validFrom": [
    2014,
    3,
    10
  ]
}

OpenAPI config example:

"validFrom": {
            "type": "string",
            "format": "date"
          }

`

I found some problems like this case. LocalDate ISO format The problems above come from the JAVA app, but my service uses the .Net app. So, how can I resolve this problem for the .Net app?

Panagiotis Kanavos
  • 120,703
  • 13
  • 188
  • 236
Khanh Tran
  • 13
  • 4
  • 2
    Knowing the serializer you're using would help greatly. I can immediately think of 4 common ways of serializing/deserializing JSON in .NET (System.Text.Json, JSON.NET, DataContractSerializer, and JavaScriptSerializer). – ProgrammingLlama Nov 04 '22 at 09:25
  • Don't use an array to pass dates in the first place. The *standard* way to pass dates in JSON is to use the ISO format. If the Java program emits an array instead of an ISO string, it has a critical bug that needs fixing – Panagiotis Kanavos Nov 04 '22 at 09:30
  • 1
    It makes no sense to handle this custom (and unusual) JSON string in .NET. All applications expect dates as ISO strings. Unless you fix the buggy Java program, you'll have to modify all clients to handle this custom form. – Panagiotis Kanavos Nov 04 '22 at 09:33
  • 2
    The date format is specified in [RFC-7493: The I-JSON format](https://www.rfc-editor.org/rfc/rfc7493#section-4.3): `It is RECOMMENDED that all such data items be expressed as string values in ISO 8601 format`. OpenAPI uses the same format for dates, so that array violates the service's own schema. – Panagiotis Kanavos Nov 04 '22 at 09:35
  • Actually never seen someone parse Date Time like that before... That java program from behind really needs a fix. – ThisQRequiresASpecialist Nov 04 '22 at 09:35
  • From the [OpenAPI spec on `date`](https://swagger.io/docs/specification/data-models/data-types/#string): ***date** – full-date notation as defined by RFC 3339, section 5.6, for example, `2017-07-21`*. The Java application is violating the schema and needs to be fixed – Panagiotis Kanavos Nov 04 '22 at 09:37
  • @KhanhTran What do you want? Do you want the code that will deserialize your json or you just want to talk about nothing? – Serge Nov 04 '22 at 11:19
  • @Serge I want to handle this problem from my side, but if it spent a lot of time to resolve and it is not worth it, I think I will try to contact my partner to resolve that. – Khanh Tran Nov 04 '22 at 14:56

1 Answers1

3

The Java application is broken and must be fixed. That array violates the application's own OpenAPI schema which says that field is an ISO8601 string.

From the OpenAPI spec on date:

date – full-date notation as defined by RFC 3339, section 5.6, for example, 2017-07-21.

ISO8601 is the standard way of serializing dates in JSON. This is specified in RFC 7493, The I-JSON format:

It is RECOMMENDED that all such data items be expressed as string values in ISO 8601 format

The Java application is violating the schema and needs to be fixed. Even if you modify a single .NET application to handle that unexpected format, other applications won't be able to handle it.

Panagiotis Kanavos
  • 120,703
  • 13
  • 188
  • 236
  • While I agree with what you're saying, I think we also need to (once OP specifies which serializer they use) provide a solution for OP with the JSON as it is in its current form, since it might be impractical for the partner to change their API just for OP's company, or they might just not be willing to. – ProgrammingLlama Nov 04 '22 at 09:44
  • @ProgrammingLlama that's impossible without the Java code. `it might be impractical for the partner to change their API just for OP's company` on the contrary, they're in clear violation of their very own OpenAPI contract. Bugs don't get clearer than that. They say, and get paid to, send you one thing, they send a completely different thing that nobody can handle. It's unlikely this is a third-party service used by multiple customers because *everyone* would be complaining about this – Panagiotis Kanavos Nov 04 '22 at 10:29
  • @ProgrammingLlama to cover up this bug one would have to modify the OpenAPI proxy generator along with creating a custom type converter, because the OpenAPI spec is claiming this is a `date`. Otherwise the OP would have to specify a type converter for ever date field every time they regenerate the proxy classes from the spec. They'll be burning money to fix someone else's bug. If it's a bank or an airline that won't fix the bug until 2024Q4 that may be the only option. In other cases though the *partner* should pay for that fix or coverup – Panagiotis Kanavos Nov 04 '22 at 10:40
  • 1
    @PanagiotisKanavos thank you. I will discuss this problem with my partner, but on the other hand they are a big company, so I think it is very difficult to change. – Khanh Tran Nov 04 '22 at 14:52