Breaking Changes for REST plugin

3.0.0.0

20 Mar 2026

RESTHost XML date-time serialization

What breaks?

This breaking change affects the XML responses sent by RESTHost services that use XML content types (application/xml or text/xml) with date-time properties. The format of date-time values in XML responses has changed. Incoming requests are not affected — Linx handles both the old and new format.

Previously, date-time values were serialized using the DateTimeOffset structure:

<DateAndTime xmlns:a="http://schemas.datacontract.org/2004/07/System">
  <a:DateTime>2026-03-18T04:37:16.196Z</a:DateTime>
  <a:OffsetMinutes>0</a:OffsetMinutes>
</DateAndTime>

Now, date-time values are serialized in the standard ISO 8601 format:

<DateAndTime>2026-03-18T04:37:16Z</DateAndTime>

Why?

The previous format used .NET's internal DateTimeOffset XML serialization, which does not conform to the format expected by the OpenAPI specification. The new format follows the standard ISO 8601 representation.

How to fix it

If you have clients that parse XML responses from a RESTHost service and depend on the previous DateTimeOffset structure (with DateTime and OffsetMinutes child elements), update them to parse the standard ISO 8601 date-time format instead.

2.0.0.0

3 May 2023

REST Multipart form data: Binary part

requestBody:
  content: 
    multipart/form-data: # Media type
      schema:            # Request payload
        type: object
        properties:      # Request parts
          myFile1:       # Part 1
            type: string
            format: binary

What breaks?

This breaking change only affects REST requests using multipart form data. Any form data containing a binary part (as Part 1 in the code section above), won't work after upgrading to this version of the plugin.

Why?

Previously binary parts of multipart form data expected a Base64 string in Linx. This upgrade corrects this and binary parts now expect binary content.

How to fix it

This can be fixed in one of two ways:

  1. Change the REST service spec to expect a Base64 part instead of a binary part in its multipart form data.
  2. Change the request to send binary content instead of a Base64 string.

Please note:

ASP.NET Core requires binary parts to have a filename specified on the request. If no filename is provided on the request, that part will be sent through as null. Multipart encoded body editor with binary part

In contrast to binary parts, Base64 parts require no filename in the request. Multipart encoded body editor with binary part