Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I want to document some wrapped json documents:
Action:
required:
- description
- name
properties:
description:
type: string
format: string
name:
type: string
format: string
Actor:
required:
- gpn
properties:
gpn:
type: string
format: string
Object:
required:
- image
- type
- url
properties:
image:
type: string
format: string
type:
type: string
format: string
url:
type: string
format: string
CreateActivity:
required:
- action
- actor
- object
- title
- externalID
properties:
action:
$ref: Action
actor:
$ref: Actor
object:
$ref: Object
title:
type: string
format: string
externalID:
type: string
format: string
And I have declared this with a $ref in Swagger
paths:
/activity:
get:
description: Returns an activity
operationId: fetchActivity
produces:
- application/json
parameters:
- name: externalActivityID
in: query
required: true
type: string
responses:
200:
description: existing activity
schema:
$ref: CreateActivity
default:
description: unexpected error
schema:
$ref: ErrorModel
The result isn't what im excepting (and i copyied the approach from pet shop). I want a object with linked entries (i.e. Action, Actor and Object are in CreateActivity with field names) and linked the request to the CreateActivity Object.
Screenshots are showing the actual situation:
the Object with the missing "subobjects"
And the missing link in the swagger documentation:
This is a known issue with swagger-editor.
Please take a look here - https://github.com/swagger-api/swagger-editor/issues/217.
Also, when you use "type": "string", there's no need to add "format":"string" as it adds no information to it. The "format" field is used to finely define the "type".
Related
I have the following schema in openapi
/submit:
post:
description: Submit info
x-openapi-router-controller: abc.def
operationId: submit_info
requestBody:
description: Submit request
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/SubmitRequest'
responses:
200:
description: submitted successfully
content:
application/json:
schema:
oneOf:
- $ref: '#/components/schemas/FooResponse'
- $ref: '#/components/schemas/BarResponse'
FooResponse:
type: object
required:
- id
- value
properties:
id:
type: string
description: id
example: '1234'
value:
type: string
description: value
example: 'foo'
BarResponse:
type: object
required:
- id
- value
- data
properties:
id:
type: string
description: id
example: '1234'
value:
type: string
description: value
example: 'foo'
data:
type: object
required:
- transaction_id
description: Data associated bar response
properties:
transaction_id:
type: string
description: transaction id
example: 'c2345'
So I have FooResponse and BarResponse. I am getting OneOf matches multiple schema error though I have different required items in FooResponse and BarResponse. It seems like openapi matches two schemas even if there are additional required items in one of the schema.
Is there a way to fix this? I want to use OneOf, but not sure how to differentiate these two schema.
Appreciate the help.
The OpenAPI Schema Object has a property called additionalProperties that specifies if properties not defined in the schema are allowed anyway in the instances(those properties are ignored).
Default value for additionalProperties is true which will cause both FooResponse and BarResponse to be valid for your instances.
Setting additionalProperties to false on FooResponse should solve the problem.
If you don't want to disallow additional properties you would have to introduce some kind of type property in both objects and use a Discriminator Object.
I'm working on implementing services compatible with Apollo GraphQL federation; my providing services are written in Lacinia (GraphQL library for Clojure).
I have one service that defines Users:
type User #key(fields: "id") {
id: String!
name: String!
}
type Query {
user_by_id(id:String!) : User
}
schema { query: Query }
and and a second that defines Products and extends Users:
type User #extends #key(fields: "id") {
id: String! #external
favorite_products: [Product]
}
type Product #key(fields: "upc") {
upc: String!
name: String!
price: Int!
}
type Query {
product_by_upc(upc: String!) : Product
}
schema { query: Query }
When I execute a query that spans services:
{
user_by_id(id: "me") {
id
name
favorite_products {
upc
name
price
}
}
}
I get a failure; the following request is sent to the products service:
INFO products.server - {:query "query($representations:[_Any!]!){_entities(representations:$representations){...on User{favorite_products{upc name price}}}}", :vars {:representations [{:__typename "User", :id "me"}]}, :line 52}
and that fails, because the products service shouldn't, as far as I know, have to provide the equivalent of __resolveReference for type User (which it extends); just type Product.
This is very unclear in the documentation and I'll experiment with providing a kind of stub reference resolver in Product for stubs of User.
Yes, indeed, you must provide the __resolveReference (or equivalent) for each type the service schema extends. In retrospect, it makes sense, as it provides the "kernel" of a raw value to be passed down the resolver tree.
I am implementing tagging functionality in my Angular MEAN stack app and so want to query the DB to retrieve all objects (in this case "NFR"s) which have one or more of those tags ("Tag" objects). Thus I have NFR objects which may contain an array of Tag objects. I have tried a number of MongoDB find queries which return nothing despite tagged records existing.
Here are some code snippets (Mongoose schema defs for NFR and Tag). Thanks very muchly in advance :-).
Katie
NFR schema:
import * as mongoose from "mongoose";
import {Tag} from "../../app/main/models/tag";
let NFR = new mongoose.Schema({
category: String,
subCategory: String,
nfr: String,
acceptanceTest: String,
source: String,
status: String,
creationDate: Date,
createdBy: String,
changeLog: String,
tags: [{
type: Tag
}]
});
Tag schema
import * as mongoose from "mongoose";
let Tag = new mongoose.Schema({
name: String,
source: String,
creationDate: Date,
_id: String
});
In the database the NFR object to search on contains two Tag objects via object id reference .
Thanks Veeram, I had to move the Tag mongoose class inside the NFR one to get it creating the associated Tag object properly (which I can now search on). This is a bad hack, not sure why it doesn't work the proper way but it will do for now.
In my Rails Application, I am trying to built API for one Model but I am not able to execute few methods. Did nt know where is wrong. Please suggest something.
Model - User
class User
include Mongoid::Document
include Mongoid::Timestamps
field :name, type: String
field :display_name, type: String
field :user_type, type: String
field :city_id, type: String
field :country_id, type: String
field :tags, type: String
field :status, type: Mongoid::Boolean
field :rating, type: Array
end
API 1. List of All User - User.All
But I am not able to take select columns name. Tried in model to define scope but still gives error. ie.
User.selected_column
scope :selected_column, -> { select("id, name") }
API 2. List of Top Rated User - User.rating_five
Tried in model to define scope but still gives error. ie.
User.rating_five
scope :rating_five, -> { .where(:rating["average"] > 4.6 ) }
Mondoid DSL is a bit different from that of Activerecord in some cases. Refer official documentation here.
First issue:
scope :selected_column, -> { only(:id, :name) }
Inorder to select specific columns.
For the second issue, try
scope :rating_five, -> { gt('rating.average': 4.6) }
Here gt represents greater than
In a mobility context of use of the API, an advanced research proposes several dynamic filters that must be returned by the server. (We don't want to make too many exchange with server to initialize our filters)
In a REST api, how to expose a enum of possible values for filter search?
Thank you for your suggestions/ideas?
My initial thought would be to treat the search like a normal resource. In an object oriented perspective, a search can have a collection of fields which can be used to filter by. These fields can be numeric, boolean, string based, or whatever.
So, if I understand your question correctly, then I would propose doing this:
GET /search_fields
If your API have multiple type searches that can be performed, then they can be identified by an id or maybe their name, as long as it is unique, like so:
GET /searches/{search_id}/fields
which would return a collection of search fields like so:
[{
name: 'Field1',
type: 'boolean'
},
{
name: 'Field2',
type: 'number'
},
{
name: 'Field3',
type: 'string'
}]
or if your fields are really just simple enums then:
[{
name: 'Field1',
id: 1
},
{
name: 'Field2',
id: 2
},
{
name: 'Field3',
id: 3
}]
That's my suggestion. Remember, there's no one right way to expose an API.