How to merge swagger multiple files in single swagger doc file? - json

I have different swagger files for multiple APIs, like swagger1.json for OpenStack API, swagger2.json for Users API etc and I was trying to merge these all swagger files in one single file using remote $ref method.
Here is swagger1.json file for OpenStack api
{
"stacks": {
"get": {
"tags": [
"openstack"
],
"summary": "Returns stacks from OpenStack",
"description": "Returns all stacks from the OpenStack based on tenantId.",
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"in": "query",
"type": "string",
"name": "tenantId",
"description": "search stacks for tenantId from OpenStack",
"required": false
}
],
"responses": {
"200": {
"description": "OK"
},
"400": {
"description": "Unknown Error"
},
"401": {
"description": "Unauthorized"
}
}
}
}
}
And this is the swagger-merge.json where I want to add multiple swagger doc file using remote reference.
{
"swagger": "2.0",
"info": {
"description": "something here",
"version": "v0.7.0",
"title": "The API Gateway",
"contact": {
"email": "dp#gmail.com"
}
},
"host": "localhost",
"port":"9191",
"basePath": "/api/openstack",
"tags": [
{
"name": "OpenStackApi",
"description": "Get stacks and running instance form OpenStack"
}
],
"schemes": [
"https"
],
"paths": {
"$ref": "./swagger1.json#/stacks"
}
}
This isn't working for me. I am not able to see API methods I have written inside swagger1.json file. I have upload swaggerUI output. Any idea about what I am doing wrong and how can I solve this issue?

You can't $ref the whole contents of paths, you can only refer individual path items:
"paths": {
"/stacks": { <--- endpoint path
"$ref": "./swagger1.json#/stacks"
}
}

Related

Autodesk Forge GET hubs returns hubs I don't have / currently use

I’m reading through the tutorial (https://forge.autodesk.com/en/docs/data/v2/tutorials/publish-model/) to automatically publish projects, and having troubles when using GET hubs –
I’m currently using postman, and set up a 3 legged auth token with data:read, data:write, and data:create using the example here - https://forge.autodesk.com/blog/3-legged-authentication-postman
I get the correct response back using GET users/#me (see below). So I think that the authentication is working properly.
"userId": "**OBSCURED**",
"userName": "shane#**OBSCURED**",
"emailId": "shane#**OBSCURED**",
"firstName": "Shane",
"lastName": "**OBSCURED**",
"emailVerified": true,
"2FaEnabled": false,
"countryCode": "US",
"language": "en",
"optin": false,
"lastModified": "2020-09-08T19:31:48.802",
"profileImages": {
"sizeX20": "https://s3.amazonaws.com:443/com.autodesk.storage.public.production/oxygen/**OBSCURED**/profilepictures/x20.jpg?r=**OBSCURED**",
"sizeX40": "https://s3.amazonaws.com:443/com.autodesk.storage.public.production/oxygen/**OBSCURED**/profilepictures/x40.jpg?r=**OBSCURED**",
"sizeX50": "https://s3.amazonaws.com:443/com.autodesk.storage.public.production/oxygen/**OBSCURED**/profilepictures/x50.jpg?r=**OBSCURED**",
"sizeX58": "https://s3.amazonaws.com:443/com.autodesk.storage.public.production/oxygen/**OBSCURED**/profilepictures/x58.jpg?r=**OBSCURED**",
"sizeX80": "https://s3.amazonaws.com:443/com.autodesk.storage.public.production/oxygen/**OBSCURED**/profilepictures/x80.jpg?r=**OBSCURED**",
"sizeX120": "https://s3.amazonaws.com:443/com.autodesk.storage.public.production/oxygen/**OBSCURED**/profilepictures/x120.jpg?r=**OBSCURED**",
"sizeX160": "https://s3.amazonaws.com:443/com.autodesk.storage.public.production/oxygen/**OBSCURED**/profilepictures/x160.jpg?r=**OBSCURED**",
"sizeX176": "https://s3.amazonaws.com:443/com.autodesk.storage.public.production/oxygen/**OBSCURED**/profilepictures/x176.jpg?r=**OBSCURED**",
"sizeX240": "https://s3.amazonaws.com:443/com.autodesk.storage.public.production/oxygen/**OBSCURED**/profilepictures/x240.jpg?r=**OBSCURED**",
"sizeX360": "https://s3.amazonaws.com:443/com.autodesk.storage.public.production/oxygen/**OBSCURED**/profilepictures/x360.jpg?r=**OBSCURED**"
},
"ldapInfo": {
"ldapEnabled": false
},
"socialUserInfoList": []
}
When I try with the same token to get hubs (using the developer docs here https://forge.autodesk.com/en/docs/data/v2/reference/http/hubs-GET/) I get the response shown below. I expect to see the accounts listed in my docs.bim360.autodesk.com projects as shown in the screenshot below. I read online that sometimes provisioning needs to be done by Autodesk to get the right stuff to show up – it seems these are hubs that I’m no longer using and set up in the early days of our bim360 account (I believe these hubs are reflective of our very first b360 project, and a test project I set up).
I’ve also tried to get projects with the hub id’s listed below, but get 404 errors saying that they do not exist.
I am also not sure if the warnings at the end of the response are the two hubs I’m looking for, because I’m writing my request wrong, or something else. I get a 200 OK back, but it seems like what I’m looking for is missing.
{
"jsonapi": {
"version": "1.0"
},
"links": {
"self": {
"href": "https://developer.api.autodesk.com/project/v1/hubs"
}
},
"data": [
{
"type": "hubs",
"id": "a.YnV**OBSCURED**NjU",
"attributes": {
"name": "**OBSCURED**",
"extension": {
"type": "hubs:autodesk.core:Hub",
"version": "1.0",
"schema": {
"href": "https://developer.api.autodesk.com/schema/v1/versions/hubs:autodesk.core:Hub-1.0"
},
"data": {}
},
"region": "US"
},
"links": {
"self": {
"href": "https://developer.api.autodesk.com/project/v1/hubs/a.YnVz**OBSCURED**uNjU"
}
},
"relationships": {
"projects": {
"links": {
"related": {
"href": "https://developer.api.autodesk.com/project/v1/hubs/a.YnVza**OBSCURED**uNjU/projects"
}
}
}
}
},
{
"type": "hubs",
"id": "a.YnVz**OBSCURED**ltNQ",
"attributes": {
"name": "shane",
"extension": {
"type": "hubs:autodesk.core:Hub",
"version": "1.0",
"schema": {
"href": "https://developer.api.autodesk.com/schema/v1/versions/hubs:autodesk.core:Hub-1.0"
},
"data": {}
},
"region": "US"
},
"links": {
"self": {
"href": "https://developer.api.autodesk.com/project/v1/hubs/a.YnVz**OBSCURED**tNQ"
}
},
"relationships": {
"projects": {
"links": {
"related": {
"href": "https://developer.api.autodesk.com/project/v1/hubs/a.YnVz**OBSCURED**ltNQ/projects"
}
}
}
}
}
],
"meta": {
"warnings": [
{
"Id": null,
"HttpStatusCode": "403",
"ErrorCode": "BIM360DM_ERROR",
"Title": "Unable to get hubs from BIM360DM US.",
"Detail": "You don't have permission to access this API",
"AboutLink": null,
"Source": [],
"meta": []
},
{
"Id": null,
"HttpStatusCode": "403",
"ErrorCode": "BIM360DM_ERROR",
"Title": "Unable to get hubs from BIM360DM EMEA.",
"Detail": "You don't have permission to access this API",
"AboutLink": null,
"Source": [],
"meta": []
}
]
}
}
Here's what I see in my docs.b360.autodesk.com portal
Am I understanding this right, that hubs are “accounts” in the above screenshot? And projects would be projects listed in those accounts/hubs?
In order to see your BIM360 accounts listed among the hubs, you do have to provision the access for every single Forge app.
And yes, the BIM360 "accounts" would show up as individual "hubs" (starting with b.) in the response of the GET hubs call.

Can a JSON API resource have an attribute which is a shorthand for a relationship?

I have a JSON API endpoint for retrieving the user. This resource will also be used to get the permissions of the user, for showing or hiding specific elements in our front end application.
The resource looks like this:
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
{
"jsonapi": {
"version": "1.0"
},
"meta": {
"content-type": "application/vnd.api+json"
},
"links": {
"self": "/users/some-uuid"
},
"data": {
"type": "users",
"id": "some-uuid",
"attributes": {
"email": "some-email#example.com",
"permissions": [
"view-all-users",
"view-all-shifts"
]
},
"relationships": {
"roles": {
"data": [
{
"type": "role",
"id": "some-role-uuid"
}
]
}
}
}
}
The permissions attribute holds the slugs for the permissions that the user has.
If this attribute was not present the front end application would have to include the resources roles and roles.permissions to be able to get to the user's permissions. That response would look like the following:
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
{
"jsonapi": {
"version": "1.0"
},
"meta": {
"content-type": "application/vnd.api+json"
},
"links": {
"self": "/users/some-uuid"
},
"data": {
"type": "users",
"id": "some-uuid",
"attributes": {
"email": "some-email#example.com",
"permissions": [
"view-all-posts",
"edit-all-posts"
]
},
"relationships": {
"roles": {
"data": [
{
"type": "role",
"id": "some-role-uuid"
}
]
}
},
"included": [
{
"type": "roles",
"id": "some-role-uuid",
"attributes": {
"name": "Editor"
},
"relationships": {
"permissions": {
"data": [
{
"type": "permission",
"id": "some-permission-uuid"
},
{
"type": "permission",
"id": "some-permission-uuid-2"
}
]
}
}
},
{
"type": "permissions",
"id": "some-permission-uuid",
"attributes": {
"slug": "view-all-posts"
}
},
{
"type": "permissions",
"id": "some-permission-uuid",
"attributes": {
"slug": "edit-all-posts"
}
}
]
}
}
In this case the front end has to do a lot of processing just to get to the permission slugs. My question here is: Is it bad to have a short hand attribute permissions on the user resource like the above example, or should the front end always get to the slugs through the relationships?
Note: In the future we will have an admin interface where the user can manage users, roles and permissions. That is why the roles and permissions are available as seperate entities.
Client apps can easily merge all the permissions from roles into one key/array themselves and work from there. This way you'll keep the principles of JSON API in tact and give the client apps the freedom to work with permissions as they prefer.

Why are the json fields returned from Autodesk Forge API for displayName different for "included" and "data" fields?

When querying a model (item) via the Autodesk Data Management Forge API:
GET projects/​:project_id/​folders/​:folder_id/​search
the returned data.attributes.displayName is sometimes different than the included.attributes.displayName for the same id. Can you explain what the difference is between "included" and "data" and which would be the one to use to get the current value of the name that is displayed in the A360 Project.
Example with the names changed and pertinent data only:
{
"jsonapi": {
"version": "1.0"
},
"links": {
},
"data": [
{
"type": "versions",
"id": "urn:adsk.wipprod:fs.file:vf.00UeaES1TmW67ZUDMfSn1A?version=3",
"attributes": {
"name": "56750_A.rvt",
"displayName": "56750_A.rvt",
}
}
}
],
"included": [
{
"type": "items",
"id": "urn:adsk.wipprod:dm.lineage:00UeaES1TmW67ZUDMfSn1A",
"attributes": {
"displayName": "343435_A.rvt",
}
}
]
}

Problems with v1/queryContext needed for SpagoBI integration

In version 1.7.0 of Orion CB running the docker version in Docker for Windows,
if I create a simple object doing POST http://localhost:1026/v1/updateContext
with the body:
{
"contextElements": [
{
"type": "Car",
"id": "myNewCar",
"attributes": [
{
"name": "maxSpeed",
"type": "integer",
"value": "220"
}
]
}
],
"updateAction": "APPEND"
}
I get the answer:
{
"contextResponses": [
{
"contextElement": {
"type": "Car",
"isPattern": "false",
"id": "myNewCar",
"attributes": [
{
"name": "maxSpeed",
"type": "integer",
"value": ""
}
]
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}
]
}
Then, if I do POST http://localhost:1026/v1/queryContext with the same headers and the same components with the body
{
"entities": [
{
"type": "Car",
"isPattern": "false",
"id": "myNewCar"
}
]
}
I get the following:
{
"errorCode": {
"code": "404",
"reasonPhrase": "No context element found"
}
}
Which shouldn't be problematic (I can query the entities with v2 API, for instance) if it wasn't needed for integration with data representation tools such as SpagoBI as documented in http://spagobi.readthedocs.io/en/latest/user/NGSI/README/
What can I do? I am doing something wrong with the context provision?
Thanks!
My problem was that I was using a imported Postman collection of the API (Downloaded from https://github.com/telefonicaid/fiware-orion/tree/develop/doc/apiary/v2) and accidentally I was using the header Fiware-Service.
You are right and your tests work properly.
Thanks for the prompt reply!!

Orion JSON Bad Request

I'm currently trying to subscribe Orion and Cosmos. All data sent to Orion is being updated without any issue. But, when posting to http://xxx.xxx.xx.xx:1026/v1/subscribeContext I'm getting the following error:
{
"subscribeError": {
"errorCode": {
"code": "400",
"reasonPhrase": "Bad Request",
"details": "JSON Parse Error"
}
}
}
This is the json string I'm sending:
{
"entities": [
{
"type": "Location",
"isPattern": "false",
"id": "Device-1"
}
],
"reference": "http://52.31.144.170:5050/notify",
"duration": "PT10S",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [
"position"
]
}
],
"attributes": [
"position"
]
}
The entity updating OK in Orion is:
{
"type": "Location",
"isPattern": "false",
"id": "Device-1",
"attributes": [
{
"name": "position",
"type": "coords",
"value": "24,21",
"metadatas": [
{
"name": "location",
"type": "string",
"value": "WGS84"
}
]
},
{
"name": "id",
"type": "device",
"value": "1"
}
]
}
I've tried with many different examples from readthedocs, and other responses in StackOverflow unsuccessfully.
Which is the correct format? Should I call /subscribeContext before or after updating Orion with /contextEntities?
Orion Context Broker version is 0.26.1.
Thank you in advance.
Taking into account that the same payload works ok when send using curl (see this execution session) I tend to think that some issue in the client (maybe hiden by a programming framework?) is causing the problem.