I'm having an issue where a simple string array or integer array creates a warning and prevents the validation of XMLs within my RAML API specification in Anypoint Platform.
These are the files I'm currently using:
customerNames.raml:
#%RAML 1.0 DataType
displayName: customerNames
description: Full detail view on a customerNames array
additionalProperties: false
properties:
customerName:
type: array
items: string
customerNames.xml:
<?xml version="1.0" encoding="UTF-8"?>
<customerNames>
<customerName>John Doe</customerName>
<customerName>Jane Doe</customerName>
</customerNames>
Validation results in the following warning:
validation error
I've tried other notations as well:
#%RAML 1.0 DataType
displayName: customerNames
description: Full detail view on a customerNames array
additionalProperties: false
properties:
customerName:
type: string[]
But to no avail.
When I try to recreate this issue using JSON files, both notations do not yield the warning and validation can happen as expected.
Is this an Anypoint Platform bug or is my syntax incorrect?
Related
I am using swagger 2.0 and I have an endpoint which is using form-data as the payload for the request, I am using the same form-data body request in several places and I don't want to write it again and again (duplicate it) and I don't know how to model it inside my yaml file (I do know how to model object when it is part of the request body as payload).
This is the form-data payload I am trying to model:
I looked at swagger's documentation: https://swagger.io/docs/specification/2-0/file-upload/
and tried to do the same but I got errors as follow:
I don't want to duplicate the same values (if I do so it will work but the solution won't be elegant).
In OpenAPI 2.0, you can only reuse the definitions of individual form fields/parameters. There's no way to reuse a set of fields/parameters.
swagger: '2.0'
parameters:
name:
in: formData
name: name
type: string
upfile1:
in: formData
name: upfile1
type: file
...
paths:
/foo:
post:
consumes:
- multipart/form-data
parameters:
- $ref: '#/parameters/name'
- $ref: '#/parameters/upfile1'
- ...
/bar:
post:
consumes:
- multipart/form-data
parameters:
- $ref: '#/parameters/name'
- $ref: '#/parameters/upfile1'
- ...
To reuse the entire request body definition, you need OpenAPI 3.0. In OAS 3, request bodies can be defined in the global components/requestBodies section and referenced using $ref:
openapi: 3.0.0
paths:
/foo:
post:
requestBody:
$ref: '#/components/requestBodies/statusMode'
responses:
...
/bar:
post:
requestBody:
$ref: '#/components/requestBodies/statusMode'
responses:
...
components:
requestBodies:
statusMode:
required: true
content:
multipart/form-data:
schema:
type: object
# The properties correspond to individual form fields
properties:
name:
type: string
upfile1:
type: string
format: binary
I try to follow exactly [this tutorial] (https://cloud.google.com/community/tutorials/exposing-aspnet-webapi-using-dotnetcore-with-cloud-endpoints ), but I get the following error at trying gcloud endpoints services deploy openapi.yaml :
ERROR: (gcloud.endpoints.services.deploy) Unable to parse Open API, or Google Service Configuration specification from [SampleSolution]
The body of openapi.yaml :
openapi: 3.0.1
info:
title: Notes API
version: v1
host: [google cloud project ID].appspot.com
paths:
/WeatherForecast:
get:
tags:
- WeatherForecast
responses:
'200':
description: Success
content:
text/plain:
schema:
type: array
items:
$ref: '#/components/schemas/WeatherForecast'
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/WeatherForecast'
text/json:
schema:
type: array
items:
$ref: '#/components/schemas/WeatherForecast'
components:
schemas:
WeatherForecast:
type: object
properties:
date:
type: string
format: date-time
temperatureC:
type: integer
format: int32
temperatureF:
type: integer
format: int32
readOnly: true
summary:
type: string
nullable: true
additionalProperties: false
I only see two things there:
openapi: 3.0.1. This should be swagger: "2.0" accordint ot the Basic structure of an OpenAPI document
host: [google cloud project ID].appspot.com. This should contain the proper project Id.
UPDATE
After checking the composition of your file and the Endpoints openAPI Docs:
OpenAPI feature limitations:
Currently, Cloud Endpoints accepts only version 2 of the OpenAPI Specification.
The Components Section in the Swagger docs mentions that applies to openAPI3. This is not compatible with point 1.
I suggest to remake your file following The basic structure of an OpenAPI document
Swashbuckle.AspNetCore now supports OpenApi 3, but it also has backwards compatibility with Swagger v2, by setting it up in Configure method (Startup class) with:
app.UseSwagger(c =>
{
c.SerializeAsV2 = true;
});
I am trying to send a templated email using Amazon SES and an API call using the following code.
Action:SendTemplatedEmail
Source: sourceemail#email.com
Destination.ToAddresses.member.1: destemail#email.com
Template: template_name
TemplateData:{"firstname":"Name"}
Tags.member.1:{"tag1name":"tag1value","tag2name":"tag2value"}
This is all working fine except the last line where im trying to add tags. After adding the last line I receive the error below.
<ErrorResponse xmlns="http://ses.amazonaws.com/doc/2010-12-01/">
<Error>
<Type>Sender</Type>
<Code>MalformedInput</Code>
<Message>Unexpected complex element termination</Message>
</Error>
<RequestId>e00f3de2-57ef-4f20-b427-959c1f1a974d</RequestId>
I think I am just not formatting the array correctly? But I have tried every combination I can think of with no luck. Any ideas?
I have also tried using
Action:SendTemplatedEmail
Source: sourceemail#email.com
Destination.ToAddresses.member.1: destemail#email.com
Template: template_name
TemplateData:{"firstname":"Name"}
Tags.member.N:["tag1name":"tag1value","tag2name":"tag2value"]
Which gives a slightly more useful error as below.
<ErrorResponse xmlns="http://ses.amazonaws.com/doc/2010-12-01/">
<Error>
<Type>Sender</Type>
<Code>ValidationError</Code>
<Message>2 validation errors detected: Value null at 'tags.1.member.name' failed to satisfy constraint: Member must not be null; Value null at 'tags.1.member.value' failed to satisfy constraint: Member must not be null</Message>
</Error>
<RequestId>e6c3bc02-d7ab-40b6-8389-7a041fdb84ce</RequestId>
Pretty sure the structure has to look like this:
Tags: [
{
Name: 'STRING_VALUE', /* required */
Value: 'STRING_VALUE' /* required */
},
/* more items */
]
Seems Message tags only applies to SendEmail and SendRawEmail API operations with Event publishing:
https://docs.aws.amazon.com/ses/latest/APIReference/API_MessageTag.html
We are struggling to import certain files into Solr occasionally. It seems like certain documents have weird meta data (values), not sure if it might be from eccentric word processor or something else. See two examples here:
Type: Solarium\Exception\HttpException
Message: Solr HTTP error: OK (400)
{"responseHeader":{"status":400,"QTime":49},"error":{"metadata":["error-class","org.apache.solr.common.SolrException","root-error-class","java.lang.NumberFormatException"],"msg":"ERROR: [doc=3932487729] Error adding field 'brightness_value'='6.18' msg=For input string: \"6.18\"","code":400}}
And
Type: Solarium\Exception\HttpException
Severity: error --> Exception: Solr HTTP error: OK (400)
{"responseHeader":{"status":400,"QTime":72},"error":{"metadata":["error-class","org.apache.solr.common.SolrException","root-error-class","java.lang.NumberFormatException"],"msg":"ERROR: [doc=16996] Error adding field 'version'='5.3.1' msg=For input string: \"5.3.1\"","code":400}}
How do we prevent these issues? We are not in control of the documents, so need to fix it on the server.
Define the field type explicitly in the schema instead of relying on Solr to create the field type for you - the first document that contains the field will make Solr guess the type of the field, and if later documents doesn't match the same, expected format, you'll get an error like this.
Always define the schema for a collection when using it in production or in an actual application - the schemaless mode is really neat for prototyping and experimenting, but in an actual application you want the types to be well defined.
I'm working on a definition/documentation-first specification of an API using Swagger 2.0. I've managed to break-out most reusable components into a definitions section however I am having trouble figuring out how to create reusable definitions for arrays of constants.
For example, I have a few paths that will return images, like this one:
paths:
/resource/{imageId}:
get:
produces:
- image/jpeg
- image/png
- image/gif
parameters:
- in: path
name: imageId
type: string
required: true
responses:
200:
description: Success
schema:
type: file
Which works just fine, but I would like to be able to define a reusable array of the values for the "produces" element so that I can reuse the same list for any path that will produce an image.
The following seemed like the intuitive approach, but swagger reports that the definition for imageMimeTypes is not valid:
paths:
/resource/{imageId}:
get:
produces:
$ref: "#/definitions/imageMimeTypes"
parameters:
- in: path
name: imageId
type: string
required: true
responses:
200:
description: Success
schema:
type: file
definitions:
imageMimeTypes:
- image/jpeg
- image/png
- image/gif
Is it possible to create a definition for an array like this? If so, what syntax should be used?
First of all, if these produces values are used in most operations, you can define them as global produces and override where needed.
produces:
- image/jpeg
- image/png
- image/gif
paths:
/resource/{imageId}:
get:
# Inherits global "produces"
...
/something:
get:
# Overrides global "produces"
produces:
- application/json
...
Your second example is not valid, because produces cannot have a $ref value. But you can use YAML anchors to achieve a similar effect. Note that an anchor must be defined before it is used, so you need to put the list above the path definition.
x-types:
imageMimeTypes: &IMAGE-MIME-TYPES
- image/jpeg
- image/png
- image/gif
paths:
/resource/{imageId}:
get:
produces: *IMAGE-MIME-TYPES
parameters:
- in: path
name: imageId
type: string
required: true
responses:
200:
description: Success
schema:
type: file
I put the list under an extension key x-types instead of definitions 1) because definitions is intended for input and output models and not random lists, and 2) to prevent the "unused definition" warning in the Swagger Editor.
This works in (at least) Swagger Editor and Swagger UI.