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

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.

Related

PayPal JSON format updating order

I know I am close on this, the error messages are getting nicer. Currently, I can call a similar call to update the seller's email no issue via Postman currently, working on updating the amount and associated objects. Something in my request format is off.
Is my breakdown section in the correct location? The amount_breakdown documentation looks like it is on same level as value and currency_code, so does it need to move into that section.
Here's my request JSON via Postman:
[
{
"op": "replace",
"path": "/purchase_units/#reference_id=='default'/amount",
"value": {
"currency_code": "CAD",
"value": "2",
"amount": {
"currency_code": "CAD",
"value": "2",
"breakdown": {
"item_total": {
"currency_code": "CAD",
"value": "2"
},
"tax_total": {
"value": "0",
"currency_code": "CAD"
}
}
},
"items": [
{
"name": "First Product Name",
"description": "Optional descriptive text..",
"unit_amount": {
"currency_code": "CAD",
"value": "2"
},
"tax": {
"value": "0",
"currency_code": "CAD"
},
"quantity": "1"
}
]
}
}
]
RESPONSE:
{
"name": "UNPROCESSABLE_ENTITY",
"details": [
{
"field": "/purchase_units/#reference_id=='default'/amount/breakdown/item_total",
"location": "body",
"issue": "ITEM_TOTAL_REQUIRED",
"description": "If item details are specified (items.unit_amount and items.quantity) corresponding amount.breakdown.item_total is required."
}
],
"message": "The requested action could not be performed, semantically incorrect, or failed business validation.",
"debug_id": "acecd3643c994",
"links": [
{
"href": "https://developer.paypal.com/docs/api/orders/v2/#error-ITEM_TOTAL_REQUIRED",
"rel": "information_link",
"method": "GET"
}
]
}
Thanks for any help!
Different variations of objects.
I can get the other PATCH operation working no issue but it is much simpler in object structure
There should be no amount key under the /amount path, and the items array does not belong at that /amount path either.

Data Management Forge API BIM 360 Item Version Relationship Refs returning no data, for acquiring Links Information

projects/:project_id/versions/:version_id/relationships/refs
method for getting
Relationships/refs
https://developer.api.autodesk.com/data/v1/projects/:project_id/versions/:version_id/relationships/refs
Using project_id: b.c2b664d6-da49-4275-8380-3b452f567532
Using version_id: urn:adsk.wipprod:fs.file:vf.0a8nbuOXTz6vhQcCyz3amw%3fversion=1
returns the following response with no data
{
"jsonapi": {
"version": "1.0"
},
"links": {
"self": {
"href": "https://developer.api.autodesk.com/data/v1/projects/b.c2b664d6-da49-4275-8380-3b452f567532/versions/urn:adsk.wipprod:fs.file:vf.0a8nbuOXTz6vhQcCyz3amw%3Fversion=1/relationships/refs"
},
"related": {
"href": "https://developer.api.autodesk.com/data/v1/projects/b.c2b664d6-da49-4275-8380-3b452f567532/versions/urn:adsk.wipprod:fs.file:vf.0a8nbuOXTz6vhQcCyz3amw%3Fversion=1/refs"
}
},
"data": []
}
I am trying to get links in the BIM 360 Revit File.
There is a bug with composite linked model items;
I had a discussion with Liang, one of the Forge Advocates, I am able to get the values for non composite linked models.
Get Request for item data
https://developer.api.autodesk.com/data/v1/projects/:project_id/items/:item_id/versions
I need to make sure my item data is isCompositeDesign: false;
"data": {
"modelVersion": 135,
"projectGuid": "3706e5cb-730c-4569-90cf-f14cd26becc8",
"originalItemUrn": "urn:adsk.wipprod:dm.lineage:Ntiy9ppQQsGCGff3bGx__Q",
"isCompositeDesign": false,
"modelType": "multiuser",
"latestEpisodeGuid": "8511e3d3-a8b8-4ca1-b9b1-ef8993aed1e5",
"mimeType": "application/vnd.autodesk.r360",
"modelGuid": "e4739730-b661-48b2-a26b-724ee3b27ef9",
"processState": "PROCESSING_COMPLETE",
"extractionState": "SUCCESS",
"splittingState": "NOT_SPLIT",
"reviewState": "NOT_IN_REVIEW",
"revisionDisplayLabel": "6",
"sourceFileName": "Test_MasterFile.rvt",
"conformingStatus": "NONE"
}
then I can get the correct response, where xrefs are my linked data:
https://developer.api.autodesk.com/data/v1/projects/:project_id/versions/:version_id/relationships/refs
"data": [
{
"type": "versions",
"id": "urn:adsk.wipprod:fs.file:vf.x8jKeZl9S2KkICKE-6avjA?version=5",
"meta": {
"refType": "xrefs",
"fromId": "urn:adsk.wipprod:fs.file:vf.Ntiy9ppQQsGCGff3bGx__Q?version=6",
"fromType": "versions",
"toId": "urn:adsk.wipprod:fs.file:vf.x8jKeZl9S2KkICKE-6avjA?version=5",
"toType": "versions",
"direction": "from",
"extension": {
"type": "xrefs:autodesk.core:Xref",
"version": "1.1",
"schema": {
"href": "https://developer.api.autodesk.com/schema/v1/versions/xrefs:autodesk.core:Xref-1.1"
},
"data": {
"nestedType": "overlay"
}
}
}
},

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.

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

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"
}
}

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!!