We have a .yml file defining the REST API, with many entries like this
/projects/{projectId}/jobs/{jobId}:
parameters:
- $ref: '#/parameters/projectId'
- $ref: '#/parameters/jobId'
get:
summary: Get Job
responses:
200:
description: Information retrieved successfully.
schema:
$ref: '#/definitions/Job'
The $ref items are not control-clickable in IDEA although they can be.
The YAML and YAML/Ansible support plugins are installed and enabled.
For me they are control clickable.
But maybe a workaround : use ctrl-B (go to declaration)
I've discovered, with the help of #Frederik here, that the Swagger Plugin does the trick. I chose the one by "Zalando" for editing and not for code generation as it has the highest rate.
Related
This question is really a followup to an earlier question here
what I am trying to do is force the consumer of my api to ONLY send Content-Type as application/json
My environment is : Mule 4.4 runtime ( on prem , no usage of Anypoint Platform )
I am defining the spec in OAS 3.0 and am using swagger editor to create and edit specification
I have the following defined :
/user:
post:
parameters:
- in: header
name: Content-Type
required: true
schema:
type: string
enum:
- application/json
and I can see a warning:
Header Parameters named 'Content-type' are ignored. The values for the 'Content-Type' header are defined by 'RequestBody.content.media-type
Tried googling and found one link here But it simply states :
Make sure that you do not use the restricted values as header parameter names.
which really does not explain of how to enforce this criteria ?
As a side note - if I copy paste the same api spec in Design centre ( Anypoint platform ) it does not complain and infact mule runtime correctly validates and rejects requests that do not have application/json in content-type
Thanks
In OpenAPI (or even RAML) we don't treat the Content-Type header as a generic HTTP header. This applies to both requests and responses. As part of the specification you can define the media types for each request. The implementation will take care of processing it correctly and validate the right Content-Type header is used at execution time. Since you are trying to set it manually the implementation is giving you an expected warning.
Example:
paths:
/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX:
post:
requestBody:
content:
application/json:
I am getting schema validation warnings "Value should be one of" when having YAML file opened with CloudFormation template. It seems that IntelliJ/WebStorm are validating YAML against remote JSON schemas if available, in this case it seems to be: https://www.schemastore.org/json/ (as stated here: https://www.jetbrains.com/help/phpstorm/yaml.html#remote_json)
But for some reason as simple type as CloudFront distribution does not validate:
Type: AWS::CloudFront::Distribution but for example Type: AWS::ECS::TaskDefinition is accepted fine. For me it looks like that https://www.schemastore.org/json/ should be up to date. Anyone else experiencing similar issues?
I also tried this plugin https://plugins.jetbrains.com/plugin/7371-aws-cloudformation, but that doesnt seem to even work when YAML validation by JSON schema is disabled:
I see there's no schedule type provided by GCP. I'd like to know the steps to create a template, a composite-type or similar, to provide Cloud Scheduler type. I know Google already provides an example about it.
If it's posible to do so by code It could make use of the python client library though it says in the documentation this library is not available, I could inline it in the code.
I cannot think of a way to authenticate against the google API to do such requests.
In short, my question is how can make Deployment Manager type for Cloud? I know it is sort of vague. Just want to know if it would be doable.
On the other hand, where can I find the official development for this
GCP service?
For completenesss here's the related Github issue too
Cloud Scheduler type is not supported yet according to GCP's documentation.
I am not aware of any official development for this GCP service other than the one I linked above. That being said, I will create a feature request for your use case. Please add any additional that I have missed and you may use the same thread to communicate with the deployment manager team.
I was looking for this functionality and thought I should give an up to date answer on the topic.
Thanks to https://stackoverflow.com/users/9253778/dany-l for the feature request which led me to this answer.
It looks like this functionality is indeed provided, just that the documentation has yet to be updated to reflect it.
Here's the snippet from https://issuetracker.google.com/issues/123013878:
- type: gcp-types/cloudscheduler-v1:projects.locations.jobs
name: <YOUR_JOB_NAME_HERE>
properties:
parent: projects/<YOUR_PROJECT_ID_HERE>/locations/<YOUR_REGION_HERE>
name: <YOUR_JOB_NAME_HERE>
description: <YOUR_JOB_DESCRIPTION_HERE>
schedule: "0 2 * * *" # daily at 2 am
timeZone: "Europe/Amsterdam"
pubsubTarget:
topicName: projects/<YOUR_PROJECT_ID_HERE>/topics/<YOUR_EXPECTED_TOPIC_HERE>
data: aGVsbG8hCg== # base64 encoded "hello!"
You can use general YAML file with deployment-manager:
config.yaml:
resources:
- name: <<YOUR_JOB_NAME>>
type: gcp-types/cloudscheduler-v1:projects.locations.jobs # Cloud scheduler
properties:
parent: "projects/<<YOUR_PROJECT_NAME>>/locations/<<YOUR_LOCATION_ID>>"
description: "<<JOB_DESCRIPTION_OPTIONAL>>"
schedule: "* */2 * * *" # accepts 'cron' format
http_target:
http_method: "GET"
uri: "<<URI_TO_YOUR_FUNCTION>>" # trigger link in cloud functions
You even can add to create a Pub/Sub job and other with deployment-manager just add :
- name: <<TOPIC_NAME>>
type: pubsub.v1.topic
properties:
topic: <<TOPIC_NAME>>
- name: <<NAME>>
type: pubsub.v1.subscription
properties:
subscription: <<SUBSCRIPTION_NAME>>
topic: $(ref.<<TOPIC_NAME>>.name)
ackDeadlineSeconds: 600
NOTE: to get <<YOUR_LOCATION_ID>> use gcloud app describe.
To deploy use:
gcloud deployment-manager deployments create <<DEPLOYMENT_NAME>> --config=<<PATH_TO_YOUR_YAML_FILE>>
To delete use:
gcloud deployment-manager deployments delete <<DEPLOYMENT_NAME>> -q
For more properties on Cloud Scheduler read the documentation:
https://cloud.google.com/scheduler/docs/reference/rpc/google.cloud.scheduler.v1#google.cloud.scheduler.v1.HttpTarget
It is possible using multiple RAML files in one APIKit Mule Project?
Let's say I have two functions /api/func1 and /api/func2.
Each of the functions is defined in its own raml - func1.raml and func2.raml.
I've generated a flow in Anypoint for the first function using the APIKit wizard. It's working ok.
Now, I'm trying generating a flow for the second function. The flow is generated with no errors. However, it just doesn't work. I've tried fixing the URLs, bindings, configurations and nothing really helps.
Note, that I don't wanna bind both the RAMLs into one file. The reason is that it's easier to develop/maintain the functions separately.
The only solution I can see is to define two separate projects. But this is not really what I'd like to do.
So, looking for an advice of how to deal with this situation.
Thanks,
Ok, actually, it's possible.
What you need to do is make the "Path"es different in the HTTP connectors for the flows generated.
The apikit wizard generates the default path that looks like this: "/api/*".
So, Mule generates an error when attempting to deploy the app. What you need to do is changing paths to "/api/func1/" and "/api/func2/"
You can continue having a single RAML file and make external references to simplify your raml, here is an example:
#%RAML 0.8
title: Eventlog API
version: 1.0
baseUri: http://eventlog.example.org/{version}
schemas:
- eventJson: !include eventSchema.json
eventListJson: !include eventlistSchema.json
Also going by strict REST design it is recommended to have a resource related details maintained in a single RAML file.
Optionally you may edit the url's to resolve any context related conflict.
One of our APIs accept certificates from our users. With current design, users dump raw certificate data in the payload and make a POST request with the content type set to application/x-pkcs12.
So essentially, our API is accepting raw bytes of a file in the body of the request.
If I try to define this API via Swagger, then I can't do so. Because, correct me if I'm wrong, the parameter of this operation will have to be 'in' body and the 'type' of this parameter would have to be file.
Swagger requires all body parameters to have the Schema object necessarily, and all parameters of type file should have 'in' value set to formData. Both of these requirements are contradictory to our case.
So my question is, is this Swagger's limitation? Or is this just bad API design, and should we be structuring/designing our API in some other way?
I'm fairly new to the world of APIs so I'm not sure which of the cases it is.
Thanks in advance.
I believe this can still be done. Your body parameter schema should have type []byte. When you call the API, your parameter value should be a base-64 encoded string of the file contents. This is similar to how you would send the contents of a binary .jpg file in the body of a request.
Swagger 2.0 allows parameters of type file. This seems to fit your use case.
parameters:
- name: cert
in: formData
description: The certificate
required: true
type: file
Your scenario is supported in OpenAPI 3.0. The previous version, OpenAPI/Swagger 2.0, allowed file uploads using multipart/form-data requests only, but 3.0 supports uploading raw files as well.
paths:
/cert:
post:
requestBody:
required: true
content:
application/x-pkcs12:
schema:
type: string
format: binary
responses:
...
More info: File Upload