Autodesk BIM360: Folder Creation returns 400 Bad request - autodesk-data-management

I called the POST-Folder Method via Postman with a JSON body according to this example. But I only receive the message "400 Bad Request" without any explanations. This is what my request looks like:
The service adress:
https://developer.api.autodesk.com/data/v1/projects/b.5823d0b2-0000-0000-00/commands
The HTTP-header
Authorization: Bearer 2_legged_token
Content-Type: application/vnd.api+json
The JSON-Body
{
"jsonapi": {
"version": "1.0"
},
"data": {
"type": "commands",
"attributes": {
"extension": {
"type": "commands:autodesk.core:CreateFolder",
"version": "1.0.0",
"data": {
"requiredAction": "create"
}
}
},
"relationships": {
"resources": {
"data": [
{
"type": "folders",
"id": "1"
}
]
}
}
},
"included": [
{
"type": "folders",
"id": "1",
"attributes": {
"name": "test",
"extension": {
"type": "folders:autodesk.bim360:Folder",
"version": "1.0.0"
}
},
"relationships": {
"parent": {
"data": {
"type": "folders",
"id": "urn:adsk.wipprod:fs.folder:co.Ai*****"
}
}
}
}
]
}
The response
{
"jsonapi": {
"version": "1.0"
},
"errors": [
{
"id": "f1266e76-a37e-400b-bff6-de84b11cdb00",
"status": "400",
"detail": "BadRequest"
}
]
}
What I have found out so far:
The project id is right. When I take a wrong project id I receive a different error.
The Json is also valid.
When I take a (surely) wrong parent-folder-urn I'll receive the same error message. So maybe this is a wrong urn format or something?

As of now, you can create a BIM 360 Docs Folder with commands endpoints, as you pointed out. For that you can use:
3-legged token
2-legged token with x-user-id header, this should contain the Autodesk User ID obtained, for instance, from GET users#me endpoint
"pure" 2-legged token will return bad request (as of August/2017)
Sorry about the documentation, the endpoint to create BIM 360 Docs folder via Commands was released a couple weeks back and we're just finishing to write the documentation.

Related

AWS LexV2 messenger channel integration not sending requestAttributes

I am building a AWS LexV2 chat bot that I want to integrate with Facebook Messenger via Channel Integration provided by LexV2. I am also using Lambda codehook to validate my inputs and fulfil my intents.
Following the docs, everything works as expected, except for one thing. When I log the event in my lambda function, requestAttributes field is missing from the object
My lambda function code:
import logging
logger = logging.getLogger()
logger.setLevel(logging.DEBUG)
def lambda_handler(event, context):
logger.error(event)
return ...
When I send a message to my app/page on facebook, this is what is logged:
{
"sessionId": "session-id",
"inputTranscript": "Intent utterance",
"interpretations":
[
{
"intent":
{
"slots":
{
"slot1": null,
"slot2": null
},
"confirmationState": "null",
"name": "IntentName",
"state": "InProgress"
},
"nluConfidence": 1.0
},
{
"intent":
{
"slots":
{},
"confirmationState": "null",
"name": "FallbackIntent",
"state": "InProgress"
}
}
],
"responseContentType": "text/plain; charset=utf-8",
"invocationSource": "DialogCodeHook",
"messageVersion": "1.0",
"sessionState":
{
"intent":
{
"slots":
{
"slot1": null,
"slot2": null
},
"confirmationState": "null",
"name": "IntentName",
"state": "InProgress"
},
"originatingRequestId": "req-id"
},
"bot":
{
"aliasId": "ALIASID",
"aliasName": "AliasName",
"name": "BotName",
"version": "DRAFT",
"localeId": "en_US",
"id": "bot-id"
},
"inputMode": "Text"
}
As you can see, no requestAttributes.
What's weird to me is that when I do the same thing for LexV1 bot (same facebook page/messenger app), I get these fields, e.g.
{
"requestAttributes":
{
"x-amz-lex:facebook-page-id": "page-id",
"x-amz-lex:channel-id": "channel-id",
"x-amz-lex:webhook-endpoint-url": "webhook-endpoint",
"x-amz-lex:accept-content-types": "PlainText",
"x-amz-lex:user-id": "user-id",
"x-amz-lex:channel-name": "channel-name",
"x-amz-lex:channel-type": "Facebook"
}
}
If anyone has any tips (other than "switch to V1") I would be very grateful. Thanks :))
Notes:
Changed Python Nones to nulls to easier format JSON
Replaced IDs and names from the logs with generic-id-slash-names

AWS API Gateway (REST) - Request Validation passes even when there is unknown property

I have an API gateway with the following schema:
{
"swagger": "2.0",
"info": {
"description": "This is a sample server Petstore server. You can find out more about Swagger at [http://swagger.io](http://swagger.io) or on [irc.freenode.net, #swagger](http://swagger.io/irc/). For this sample, you can use the api key `special-key` to test the authorization filters.",
"version": "1.0.0",
"title": "Swagger Petstore",
"termsOfService": "http://swagger.io/terms/",
"contact": {
"email": "apiteam#swagger.io"
},
"license": {
"name": "Apache 2.0",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html"
}
},
"paths": {
"/pet": {
"post": {
"summary": "Add a new pet to the store",
"description": "",
"operationId": "addPet",
"consumes": [
"application/json",
"application/xml"
],
"produces": [
"application/xml",
"application/json"
],
"parameters": [
{
"in": "body",
"name": "body",
"description": "Pet object that needs to be added to the store",
"required": true,
"schema": {
"$ref": "#/definitions/Pet"
}
}
],
"responses": {
"405": {
"description": "Invalid input"
}
}}
}},
"definitions": {
"Pet": {
"required": ["id", "name"],
"type": "object",
"properties": {
"id": {
"type": "integer",
"description": "Id of the pet",
"example": 123
},
"name": {
"type": "string",
"description": "Name of the pet",
"example": "Jammy"
},
"nickname": {
"type": "string",
"description": "Nickname of the pet",
"example": "Jam"
}
}
}
}
}
When I send a request body with fields which are not present in the schema, I don't get 400 response from API gateway. I have applied the configuration to Validate body, headers, query string.
Is this an open issue in API gateway? Or am I missing something?
So with swagger v2 and openapiv3 specs the default behavior is to accept all additional properties that your spec does not define. If you include the required pet id and name and additional unused propertues like foo and bar, you post should succeed.
If you want more strict validation that fails when additional properties are sent then set additionalProperties to false in your pet schema or do that and change the spec version to 3.x.x

Alexa is 'Unable to Reach the Requested Skill'

I'm receiving "I'm unable to reach the requested skill" message from an Alexa dashboard testing console for the skill that used to work before (with no modifications to any underlying infrastructure or code).
Here's the error obtained from Alexa's device logs:
{
"header": {
"namespace": "SkillDebugger",
"name": "CaptureError",
"messageId": "57d00be6-19d6-4529-b0b1-4c5d6c2760ac"
},
"payload": {
"skillId": "amzn1.ask.skill.db1bac88-183d-409c-9d3e-0e69fa0f5fe2",
"timestamp": "2018-09-27T19:11:51.066Z",
"dialogRequestId": "d9ec106d-2ef2-4526-a156-f4714ce5d034",
"skillRequestId": "amzn1.echo-api.request.1e166266-56e1-4c51-b40a-3ceb144f997f",
"code": "SKILL_ENDPOINT_ERROR",
"description": "An error occurred while issuing a SpeechletRequest for (requestId [amzn1.echo-api.request.1e166266-56e1-4c51-b40a-3ceb144f997f]",
"debuggingInfo": {
"type": "SkillExecutionInfo",
"content": {
"invocationRequest": {
"endpoint": "https://emptio.serveo.net/abc/api/v1/alexa",
"body": {
"version": "1.0",
"session": {
"new": false,
"sessionId": "amzn1.echo-api.session.bfc02d53-fe83-4c70-b731-ea7ede99d20a",
"application": {
"applicationId": "amzn1.ask.skill.db1bac88-183d-409c-9d3e-0e69fa0f5fe2"
},
"user": {
"userId": "amzn1.ask.account.AGX2NO3NXXDS6NLEZMDZXMRZZPJ3DLEERYK7J3NUPFUYRADFB2HRILB7BZVTN336OFVSNFFUP3VDVFHERK5PKQE5H32EQ5GGWTT67EMDQKP22Q7NTXXNYDUTYNCYI6EJUEODQ54VHKW4JSWVCS7JINWLYH2LICQVETFGZBY6NBDJVEX66VCGCZMRTFZYAG2E3IXDPMPVF3U4VMY",
"accessToken": "Atza|IwEBIM_YZylf-iVoydW0WhXTS4ykk6oA0FwI9Aa7Pdz_pysLPaL1AJwQLXA-Y1GJabHTWMJxfDEKyIiLFuxEPnTxuYaEDyany7WXzHMOd0-iiD9lYBxE6rIXkC3Z-I5PYU6DQtkT6DHxbusrkyGTb1bSfbznIaaFat3yNvKY9mXaNHEEhuuPRZJkXjffBA9WKzWrkGetOdHVvo-PLw2w9rWUiQQuJ6ryzQjugYILyCuTry3qz8lvqWGxYX0XB3dx_CGuzjEnNP0-X2ozhLXN8cBjtBrl7MlTffNyo6K94vi24-16bdIdFZG3mVL_bKSCXzAx2qzPJvBCn953FrPVw9zd7CtOintRSBDZ9Aw_QgKqTklliWTBP_8uRqq_nuMB8s992-Yhi6Zb-k7VvyYp7oLtJ8ggRqRlRk9vS4HBxyfKCxvfXmvlmZJlAtGjec_-Bx8UB2pf1ZH0xi-2LYpezVh2e7dgWenKU0PHvtduprVtpO4E72148mddcYyQRzAEdk8LYQx1SiamYY64_qmkv14h1qBPUIQPuv3MFt2PB7Mhm6cVTA"
}
},
"context": {
"System": {
"application": {
"applicationId": "amzn1.ask.skill.db1bac88-183d-409c-9d3e-0e69fa0f5fe2"
},
"user": {
"userId": "amzn1.ask.account.AGX2NO3NXXDS6NLEZMDZXMRZZPJ3DLEERYK7J3NUPFUYRADFB2HRILB7BZVTN336OFVSNFFUP3VDVFHERK5PKQE5H32EQ5GGWTT67EMDQKP22Q7NTXXNYDUTYNCYI6EJUEODQ54VHKW4JSWVCS7JINWLYH2LICQVETFGZBY6NBDJVEX66VCGCZMRTFZYAG2E3IXDPMPVF3U4VMY",
"accessToken": "Atza|IwEBIM_YZylf-iVoydW0WhXTS4ykk6oA0FwI9Aa7Pdz_pysLPaL1AJwQLXA-Y1GJabHTWMJxfDEKyIiLFuxEPnTxuYaEDyany7WXzHMOd0-iiD9lYBxE6rIXkC3Z-I5PYU6DQtkT6DHxbusrkyGTb1bSfbznIaaFat3yNvKY9mXaNHEEhuuPRZJkXjffBA9WKzWrkGetOdHVvo-PLw2w9rWUiQQuJ6ryzQjugYILyCuTry3qz8lvqWGxYX0XB3dx_CGuzjEnNP0-X2ozhLXN8cBjtBrl7MlTffNyo6K94vi24-16bdIdFZG3mVL_bKSCXzAx2qzPJvBCn953FrPVw9zd7CtOintRSBDZ9Aw_QgKqTklliWTBP_8uRqq_nuMB8s992-Yhi6Zb-k7VvyYp7oLtJ8ggRqRlRk9vS4HBxyfKCxvfXmvlmZJlAtGjec_-Bx8UB2pf1ZH0xi-2LYpezVh2e7dgWenKU0PHvtduprVtpO4E72148mddcYyQRzAEdk8LYQx1SiamYY64_qmkv14h1qBPUIQPuv3MFt2PB7Mhm6cVTA"
},
"device": {
"deviceId": "amzn1.ask.device.AGUTTO7VCXPCUUSXNDCNO6LK7LZHUKPDGZBOXUOBNRNOBGD7FHBJWHOK3LJNQX4U47HTFLUXJ6MHBL6V7UCDNTWOMBJIP5R4R2ZVK3XJX42PEZG6J6TCS3U7NSYZZ3PDCUSH22CY7LYGNIK2MGXCUGR4ITQQ",
"supportedInterfaces": {}
},
"apiEndpoint": "https://api.amazonalexa.com",
"apiAccessToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJhdWQiOiJodHRwczovL2FwaS5hbWF6b25hbGV4YS5jb20iLCJpc3MiOiJBbGV4YVNraWxsS2l0Iiwic3ViIjoiYW16bjEuYXNrLnNraWxsLmRiMWJhYzg4LTE4M2QtNDA5Yy05ZDNlLTBlNjlmYTBmNWZlMiIsImV4cCI6MTUzODA3OTEwNywiaWF0IjoxNTM4MDc1NTA3LCJuYmYiOjE1MzgwNzU1MDcsInByaXZhdGVDbGFpbXMiOnsiY29uc2VudFRva2VuIjpudWxsLCJkZXZpY2VJZCI6ImFtem4xLmFzay5kZXZpY2UuQUdVVFRPN1ZDWFBDVVVTWE5EQ05PNkxLN0xaSFVLUERHWkJPWFVPQk5STk9CR0Q3RkhCSldIT0szTEpOUVg0VTQ3SFRGTFVYSjZNSEJMNlY3VUNETlRXT01CSklQNVI0UjJaVkszWEpYNDJQRVpHNko2VENTM1U3TlNZWlozUERDVVNIMjJDWTdMWUdOSUsyTUdYQ1VHUjRJVFFRIiwidXNlcklkIjoiYW16bjEuYXNrLmFjY291bnQuQUdYMk5PM05YWERTNk5MRVpNRFpYTVJaWlBKM0RMRUVSWUs3SjNOVVBGVVlSQURGQjJIUklMQjdCWlZUTjMzNk9GVlNORkZVUDNWRFZGSEVSSzVQS1FFNUgzMkVRNUdHV1RUNjdFTURRS1AyMlE3TlRYWE5ZRFVUWU5DWUk2RUpVRU9EUTU0VkhLVzRKU1dWQ1M3SklOV0xZSDJMSUNRVkVURkdaQlk2TkJESlZFWDY2VkNHQ1pNUlRGWllBRzJFM0lYRFBNUFZGM1U0Vk1ZIn19.LzPCt8QPxkEa5jFK3IMGMQLWS3vXOopyGKBu0cAy1cnJzAk7wnbKwc9eyQYDMr3uH7MyHr4s7xUKpWlvspGOAL3LqKxFbxqpB5zIjhKifqdGQhB_nurOAjeyZOipZ0ZhSuPN9fqTwp7zwca4LdYz6Kuahklz7D7pU7ICNI1DNqNKDx9HmyWbJIwXWL3MvS9sEujDo15oTdiueNaCbC7kLnPi0adrukHy3J6HVN_XjWS5mSSawuObgiT2b9eLm4qntoMG7MnDTSrzxmhKgXm3WrbFxRW_ZKE3uu1wa7-412f8DPxvbVZkeYDRwWMTO8s7BtnzjPcKEcT6daLXKRgpVw"
}
},
"request": {
"type": "SessionEndedRequest",
"requestId": "amzn1.echo-api.request.1e166266-56e1-4c51-b40a-3ceb144f997f",
"timestamp": "2018-09-27T19:11:47Z",
"locale": "en-US",
"reason": "ERROR",
"error": {
"type": "INVALID_RESPONSE",
"message": "An exception occurred while dispatching the request to the skill."
}
}
}
},
"invocationResponse": null,
"metrics": {
"skillExecutionTimeInMilliseconds": 3107
}
}
}
}
}
As is seen from the above response, the skill is configured with an endpoint: https://emptio.serveo.net/abc/api/v1/alexa which is perfectly reachable.
Again, the same exact skill used to work just yesterday. The invocation name under which I am calling it used to work fine.
I'm able to reach and verify the above endpoint is functional and responsive outside Alexa, but it's somehow not reachable from the Alexa dashboard.
I'm monitoring the logs from Serveo - they don't show any activity, meaning that something is broken before the webhook is called.
What could be the reason for the error? How can I debug what is going on in the Alexa stack?
Make sure option for the endpoint's SSL certificate type is correct. You can change this in the endpoint option in the web development console.
Your host might be using a wildcard certificate so select the wildcard option, save your endpoint again - then test again using the console for reachability.

Google People API does not return an emailAddress for people/me

I'm using the Google API Console Tool tool, and when I do the query
resourceName: people/me
personFields: emailAddresses
I get the following response:
{
"resourceName": "people/102381120202845324999",
"etag": "%EgUBCT43LhoMAQIDBAUGBwgJCgsMIgw0eHhmblFCa0Qybz0="
}
As you can see, no email address is included. This only happens with one of my gmail accounts. Using another account I would get a response like:
{
"resourceName": "people/104150119553351608999",
"etag": "%EgUBCT43LhoMAQIDBAUGBwgJCgsMIgxIc2JBaWZXWldGQT0=",
"emailAddresses": [
{
"metadata": {
"primary": true,
"verified": true,
"source": {
"type": "DOMAIN_PROFILE",
"id": "104150119553351608710"
}
},
"value": "xx#example.com"
}
}
Any idea what the cause could be?
I think this is related to G Suite.

JSONAPI: Update relationships including attributes

I have a nested object in my SQLAlchemy table, produced with Marshmallow's nested schema feature. For example, an articles object GET response would include an author (a User type) object along with it.
I know that the JSONAPI spec already allows updating relationships. However, often I would like to update an article as well with its nested objects in one call (POST requests of articles that include a new author will automatically create the author). Is it possible to make a PATCH request that includes the resources of a relationship object that doesn't yet exist?
So instead of just this:
PATCH /articles/1 HTTP/1.1
Content-Type: application/vnd.api+json
Accept: application/vnd.api+json
{
"data": {
"type": "articles",
"id": "1",
"relationships": {
"author": {
"data": { "type": "people", "id": "1" }
}
}
}
}
It'd be ideal to pass this in to create a new author if there didn't exist one (this is not my actual use case, but I have a similar real life need):
PATCH /articles/1 HTTP/1.1
Content-Type: application/vnd.api+json
Accept: application/vnd.api+json
{
"data": {
"type": "articles",
"id": "1",
"relationships": {
"author": {
"data": { "type": "people", "id": "1", "attributes": {"name": "new author":, "articles_written": 1} }
}
}
}
}
Is this at all possible or have suggestions on what REST frameworks can support this, or would it be totally against the JSON API spec?
Updating multiple resources at once is not possible with JSON API spec v1.0. But there are several suggestions how to do that. Both official extensions which are not supported anymore aimed to support creating, updating or deleting multiple request at once. Also there is an open pull request which would introduce operations to upcoming JSON API spec v1.2.
For example a request updating two resources at once using suggested operations[1] would look like this:
PATCH /bulk HTTP/1.1
Host: example.org
Content-Type: application/vnd.api+json
{
"operations": [{
"op": "update",
"ref": {
"type": "articles",
"id": "1"
},
"data": {
"type": "articles",
"id": "1",
"attributes": {
"title": "Updated title of articles 1"
}
}
}, {
"op": "update",
"ref": {
"type": "people",
"id": "2"
},
"data": {
"type": "people",
"id": "2",
"attributes": {
"name": "updated name of author 2"
}
}
}]
}
This would update title attribute of article with id 1 and name attribute of person resource with id 2 in a single transaction.
An request to update a to-one relationship and updating the related resource in a singular transaction would look like this:
PATCH /bulk HTTP/1.1
Host: example.org
Content-Type: application/vnd.api+json
{
"operations": [{
"op": "update",
"ref": {
"type": "articles",
"id": "1",
"relationship": "author"
},
"data": {
"type": "people",
"id": "2"
}
}, {
"op": "update",
"ref": {
"type": "people",
"id": "2"
},
"data": {
"type": "people",
"id": "2",
"attributes": {
"name": "updated name of author 2"
}
}
}]
}
This is a request which creates a new person and associate it as author to an existing article with id 1:
PATCH /bulk HTTP/1.1
Host: example.org
Content-Type: application/vnd.api+json
{
"operations": [{
"op": "add",
"ref": {
"type": "people"
},
"data": {
"type": "people",
"lid": "a",
"attributes": {
"name": "name of new person"
}
}
}, {
"op": "update",
"ref": {
"type": "articles",
"id": "1",
"relationship": "author"
},
"data": {
"type": "people",
"lid": "a"
}
}]
}
Note that the order is important. Operations must be performed in order by server. So the resource has to be created before it could be associated to an existing one. To express the relationship we use a local id (lid).
Please note that operations should only be used if a request has to be performed transactionally. If each of the included operations could be executed atomically, singular requests should be used.
Accordingly to implementation list provided on jsonapi.org there are some libraries supporting Patch extension.
Update: Operations were not included in release candidate for JSON API v1.1. It's planned for v1.2 now. The author of the pull request, which is also one of the maintainers of the spec, said that "operations are now the highest priority". A release candidate for v1.2 including Operations may be shipped "RC within a few months of 1.1 final."
[1] Introducing operations to JSON API v1.2 is currently only suggested but not merged. There may be breaking changes. Read the related pull request before implementation.