I'm trying to model a GET request in my RAML that has an arbitrary list of URL parameters. 2 parameters are known, but the remainder are name/value pairs that are chosen from the response data from other request types. I tried to use additionalParameters: true in my queryParameters list, but I get an error message from osprey-mock-service when it attempts to parse the RAML:
each query parameter must be a map
The relevant snippet from my RAML is:
/statistics:
/{statisticId}:
get:
description: Get the stastic data
queryParameters:
start:
displayName: Start Time
type: integer
description: The timstamp in milliseconds indicating the beginning of the collection of timeseries data
example: 1380601800000
required: false
end:
displayName: End Time
type: integer
description: The timstamp in milliseconds indicating the end of the collection of timeseries data
example: 1380601800000
required: false
additionalParameters: true
responses:
200:
body:
application/json:
schema: statistic
example: !include ../dto/statistic.sample
The error message goes away when I remove the line:
additionalParameters: true
I have not found a reference that indicates that you can use additionalParameters with queryParameters, but it seems to make sense that you could.
I don't necessarily need to resolve the error message, but I would like to have URL parameters like the following:
?start=23010030&end=23011470&content=abc.com&node=siteA
Where content and node are not predefined parameter names.
Is this possible?
additionalParameters is currently not supported by RAML: it is nowhere to be found in version 0.8 of the specification.
This said, this (very important) topic is under discussion in the RAML forums
So for the moment, I see only two options:
Do not specify these parameters, the caveat being that tools, like RAML Tester, will report request violations if you use these parameters.
Specify all the possible parameters with required: false, the caveat being that you need to know all these parameters beforehand.
Related
I am a little confused by Swagger's enum support for OpenAPI3.0. My point here being that there have been new improvements in swagger doc where there is support for re-usable enums as
documented here:
https://swagger.io/docs/specification/data-models/enums/
where support for reusable enums is stated using $ref. However, when I post my swagger.json to swagger editor/validator which looks like following
in: query
name: prop-name
description: something
type: array
items:
$ref: '#/definitions/mytype'
which is further defined below:
mytype:
enum:
- Item1
type: string
Swagger editor throws an error and says should NOT have additional properties
additionalProperty: $ref
Now, this is not a problem when loading the swagger page and attaining the functionality but it is an issue when it comes to using swagger-gen and generating clients using it. the swagger-gen CLI also throws the same error causing us to now being able to generate a client for this page correctly.
Is there anything wrong with this swagger.json? I there any extra information that I can provide to shed light on this issue?
In OpenAPI 2.0, array parameter schemas cannot use $ref. You must define the enum inline:
- in: query
name: prop-name
description: something
type: array
items:
type: string
enum:
- Item1
I'm trying to instance multiple objects of diverse types based on what you set on the config file.
Also, I'm trying to avoid to use the 'switch' statement with every Type of object that you can instance.
My original idea was use sort type of reflection, to create a object with a Type obtained from a config value.
For example:
These is a YAML Config example
workers:
- type: "Type1"
parameters:
param_0: "test"
param_1: 1000
- type: "Type2"
parameters:
param_0: "test"
param_1: 1000
When these settings are analyzed; at run-time, the program must instance a "Type1" object with the "Parameters"; and then another instance of a "Type2" object with its "Parameters".
Please let me know if you need more information about it.
PD: Sorry for my bad English.
I am trying to prototype a trigger using the Zapier CLI and I am running to an issue with the 'Pull In Samples' section when setting up the trigger in the UI.
This tries to pull in a live sample of data to use, however the documentation states that if no results are returned it will use the sample data that is configured for the trigger.
In most cases there will be no live data and so ideally would actually prefer the sample data to be used in the first instance, however my trigger does not seem to ever use the sample and I have not been able to find a concrete example of a 'no results' response.
The API I am using returns XML so I am manipulating the result into JSON which works fine if there is data.
If there are no results so far I have tried returning '[]', but that just hangs and if I check the zapier http logs it's looping http requests until I cancel the sample check.
Returning '[{}]' returns an error that I need an 'id' field.
The definition I am using is:
module.exports = {
key: 'getsmsinbound',
noun: 'GetSMSInbound',
display: {
label: 'Get Inbound SMS',
description: 'Check for inbound SMS'
},
operation: {
inputFields: [
{ key: 'number', required: true, type: 'string', helpText: 'Enter the inbound number' },
{ key: 'keyword', required: false, type: 'string', helpText: 'Optional if you have configured a keyword and you wish to check for specific keyword messages.' },
],
perform: getsmsinbound,
sample: {
id: 1,
originator: '+447980123456',
destination: '+447781484146',
keyword: '',
date: '2009-07-08',
time: '10:38:55',
body: 'hello world',
network: 'Orange'
}
}
};
I'm hoping it's something obvious as on scouring the web and Zapier documentation I've not had any luck!
Sample data must be provided from your app and the sample payload is not used for this poll specifically. From the docs:
Sample results will NOT be used for a user's Zap testing step. That
step requires data to be received by an event or returned from a
polling URL. If a user chooses to "Skip Test", then the sample result,
if provided, will be used.
Personally, I have never seen "Skip Test" show up. A while back I asked support about this:
That's a great question! It's definitely one of those "chicken and
egg" situations when using REST Hooks - if there isn't a sample
available, then everything just stalls.
When the Zap editor tries to obtain a "sample result", there are three
places where it's going to look:
The Polling endpoint (in Step #3 of your trigger's setup) is invoked for the current user. If that returns "nothing", then the Zap
editor will try the next step.
The "most recent record/data" in the Zap's history. Since this is a brand new Zap, there won't be anything present.
The Sample result (in Step #4 of your trigger's setup). The Zap editor will tell the user that there's "nothing to show", and will
give the user the option to "skip test and continue", which will use
the sample JSON that you've provided here.
In reality, it will just continue to retry the request over and over and never provide the user with a "skip test and continue" option. I just emailed again asking if anything has changed since then, but it looks like existing sample data is a requirement.
Perhaps create a record in your API by default and hide it from normal use and just send back that one?
Or send back dummy data even though Zapier says not to. Not sure, but I don't know how people can set up a zap when no data has been created yet (and Zapier says not many of their apps have this issue, but nearly every trigger I've created and ever use case for other applications would hint to me otherwise).
I'm writing some RAML in an API designer and I have the following code:
/users:
/{id}:
/tags:
description: Personal tags of a user
get:
description: A list of the user's personal tags
responses:
200:
body:
application/json:
example: |
{
tags: [
{...},
...
]
}
/{slug}:
description: A personal tag
put:
The parser is throwing an error at /{slug} because it thinks that I'm trying to use it as a property of the get: method. However, /{slug} needs to be indented to make it subordinate to /tags.
Is there a way in RAML (or YAML, since RAML is supposed to be an instance of YAML), to mark the end of a map? Or do you have any other suggestions?
RAML doesn't (AFAIK) support explicit termination of maps, but we also don't need that to solve your problem :-).
Since in YAML the whitespace is semantic, what's happening is that your GET method is currently indented such that it's a method on the /users/{id} level, so even though it looks like /{slug} is subordinate to tags, it thinks it is in the definition of /users/{id} Really, we should probably throw an error here, since the method definition comes after you've defined a sub-resource (thanks for finding this case).
To solve, all you need to do is indent your description and get definition for /users/{id}/tags one additional level, and it should all parse fine. Updated RAML is below.
/users:
/{id}:
/tags:
description: Personal tags of a user
get:
description: A list of the user's personal tags
responses:
200:
body:
application/json:
example: |
{
tags: [
{...},
...
]
}
/{slug}:
description: A personal tag
put:
I'm using Kwalify for schema validation. One part of the YAML document actually does want to allow for key names of a certain type in a mapping.
I see that Kwalify support regexes for the values in a mapping, but I see no such mention of support for using regexes in the keys in a mapping. Here's what I'd like to support validating:
test-element:
sub-element-1: test
sub-element-2:
element-with-pattern-1: test1
element-with-pattern-2: test2
So I don't know what some key names will exactly be in advance (shown here with the fake names "element-with-pattern-*", but I do know that they should correspond to a pattern defined by a regex.
Is this possible to validate using Kwalify?
To check this:
parent_key:
random_key1: url1
random_key2: url2
you should use "Default of Mapping", here is schema example:
type: map
mapping:
"parent_key":
type: map
mapping:
"=":
type: str
http://www.kuwata-lab.com/kwalify/ruby/users-guide.02.html#tips-default
I do not believe it's possible given the current state of the code.
I'm actually in a similar situation, which I found out (the hard way) does not work well for validation in the Kwalify context. I've begun migrating away from flexible key names into a paradigm where I can specifically define the schema.
For example, I migrated this:
parent_key:
random_key1: url1
random_key2: url2
To:
parent_key:
- name: random_key1
url: url1
- name: random_key2
url: url2
With the latter syntax, you can validate like this:
"parent_key":
type: seq
sequence:
- type: map
mapping:
"name":
type: str
required: yes
"url":
type: str
required: yes
Within that context, you can add a pattern regex validators to either name or url that should allow you to achieve your goal.