OneFS 8.1.0 Freight Trains support

[Atomicology]

In the following example POST response body schema, the properties will be pulled from the success object rather than the errors object:

POST response body schema:
{
  "type": [
    {
      "additionalProperties": false, 
      "type": "object", 
      "description": "A list of errors that may be returned.", 
      "properties": {
        "errors": {
          "items": {
            "additionalProperties": false, 
            "type": "object", 
            "description": "An object describing a single error.", 
            "properties": {
              "field": {
                "type": "string", 
                "description": "The field with the error if applicable."
              }, 
              "message": {
                "type": "string", 
                "description": "The error message."
              }, 
              "code": {
                "type": "string", 
                "description": "The error code."
              }
            }
          }, 
          "type": "array"
        }
      }
    }, 
    {
      "type": "object", 
      "properties": {
        "id": {
          "minLength": 0, 
          "required": true, 
          "type": "string", 
          "description": "ID of created item that can be used to refer to item in the collection-item resource path.", 
          "maxLength": 255
        }
      }
    }
  ]
}

[cbrainerd]

Is it a safe assumption that the last item in the types list will always be where we want to take properties from? We won't ever see for example, the errors schema in the last position?

[Atomicology]

@cbrainerd The errors object is added to the response body schema with a default wrapper, so it will always be the first object in the list. As an additional safeguard, I could verify that the errors key does not exist in the properties, but that could potentially exclude a valid response. Thus, I chose to rely on the default behavior for the Platform API.