What do I need to put in the reference attribute?
I'm using two forms, and the two are bad for Orion Context Broker:
URL url = new URL("http://130.206.127.23:1026/ngsi10/notifyContext");
//String url = "http://localhost:1028/accumulate";
cabecera.put("reference", ""+url);
With this code, I'm generating the next JSON String for the reference attribute
...."reference":"http:\/\/130.206.127.23:1026\/ngsi10\/notifyContext",...
And this is the response of OCB
<subscribeContextResponse>
<subscribeError>
<errorCode>
<code>400</code>
<reasonPhrase>Bad Request</reasonPhrase>
<details>JSON Parse Error: <unspecified file>(1): invalid escape sequence</details>
</errorCode>
</subscribeError>
</subscribeContextResponse>
Also related to this parameter,do I need a program in execution in a server to receive the information about my subscription?
Can I get a program from Orion Context Broker resources to do this task?
The following is my JSON to call the service, but I'm not sure about the reference attribute. I want to send a subscription to my Orion Context Broker instance. I'm sending this JSON:
{
"duration": "P1M",
"reference": "http://130.206.127.23:1026/ngsi10/notifyContext",
"notifyConditions": [
{
"condValues": [
"PT10s"
],
"type": "ONTIMEINTERVAL"
}
],
"entities": [
{
"id": "1.0",
"type": "Capsule",
"isPattern": "false"
}
],
"attributes": [
"temperature"
]
}
Thanks in advance.
The reference element is described in the Orion User Manual:
The callback URL to send notifications is defined with the reference
element.
Thus, if your reference is http://130.206.127.23:1026/ngsi10/notifyContext as shown in your example, you should have a REST server listening at host 130.206.127.23 port 1026, able to receive notifications in the /ngsi10/notifyContext path. Note that your CB (I mean, the one to which you are sending the subscribeContext request) is the actor that sends notification, not the actor that receives them, so it must not run at 130.206.127.23:1026.
You can implement the notifications receiver program in any programming language that you want (as long as it implements the required REST server interface). You can have a look to the accumulator-server.py, which is a "dummy" notification receiver example implemented in Python, used for testing.
Related
We are integrating the MS Graph API's in our c# application. sending mail is working fine by following this article Send Mail Documentation. But I am facing an issue with ConversationIndex (Mainly Threads).
ConversationIndex of mail sent via API is different than recipients' replies to the same mail. Due to this it is unable to identify the threads.
This is the payload used to send mail. can anybody help me with any key or property I am missing while sending mail?
{
"message": {
"subject": "Meet for lunch?",
"body": {
"contentType": "Text",
"content": "The new cafeteria is open."
},
"toRecipients": [
{
"emailAddress": {
"address": "fannyd#contoso.onmicrosoft.com"
}
}
],
"ccRecipients": [
{
"emailAddress": {
"address": "danas#contoso.onmicrosoft.com"
}
}
]
},
"saveToSentItems": "false"
}
Structure of Conversation Index
[reserved-1B] [timestamp-5B] [GUID-16B] [timestamp-5B][timestamp-5B]…[timestamp-5B]
<-------------Header Block----------------><-------------------Child Blocks------------------>
All messages part of the same conversation thread has the same 16-Bytes GUID.
5-Bytes [timestamp] in Header Block: System time when message was received converted into FILETIME format.
5-Bytes [timestamp] in Child Blocks: Child blocks are present only for Outlook messages, to indicate subsequent messages in a thread while keeping the header block attributes same. Every message reply to a conversation adds a [timestamp] at end to create a new conversationIndex.
Relative ordering of messages belonging to same conversation thread:
For all messages belonging to same GUID, SORT the messages by conversationIndex values.
Please refer to documentations here to understand better.
Tracking conversations
ConversationIndex property
I am trying to use https://github.com/ibm-watson-iot/openwhisk-package-watsoniotp in an OpenWhisk sequence (containing two actions) all code is node.js
Testing the sequence using Postman. Once the action completes, the action returns the variable, payload. The variable payload is passed over to the next action in the sequence which is the openwhisk-package-watsoniotp (added via a binding in the IBM Cloud console so I am unable to modify this code, it is locked).
I can post data from postman into Watson IoT platform via the sequence. However the format of the payload is interpreted as a String, not a JSON string.
This is the body I post from Postman, one of the variants I have tried.
{"payload": "{'speed': 10}"}
My node.JS actions return the input, unmodified.
return {payload: params.payload};
The value should be a JSON string. However WIOTP is unable to interpret the payload and basically tokenizes the values. This is evident when I try to create a board and a card. The property list lets me select each value in the array.
enter image description here
The openwhisk-package-watsontiotp code as far as I can tell just takes, params.payload as is and passes it along.
I found an example in the code that answer the question,
The payload, should be nested. I missed that originally.
{
"key": "sampleInput",
"value": {
"eventType": "status",
"payload": {
"temp": 4
},
"domain": "messaging.internetofthings.ibmcloud.com",
"typeId": "xxxx",
"deviceId": "xxxx01"
}
}
Currently, I'm working on new product and making REST API for both - public and internal needs. I started with {json:api} specification and I was pretty happy with it until I faced some questions I cannot find answers to.
According to JSON API specification, every resource MUST contain id.
http://jsonapi.org/format/
Every resource object MUST contain an id member and a type member. The values of the id and type members MUST be strings.
And that's fine in many cases but not all.
Most of our endpoints are about "resources"
If I ask for a "things" collection (http://example.com/things)
{
"data": [{
"type": "things",
"id": "1",
"attributes": {
"title": "first"
},
"links": {
"self": "http://example.com/things/1"
}
}, {
"type": "things",
"id": "1",
"attributes": {
"title": "second"
},
"links": {
"self": "http://example.com/things/2"
}
}]
}
If I ask for a single "things" resource (http://example.com/things/1)
{
"data": {
"type": "things",
"id": "1",
"attributes": {
"title": "first"
},
"links": {
"self": "http://example.com/things/1"
}
}
}
But what to do with endpoints which are not about resources and does not have ID?
For example, in our application, there is an endpoint http://example.com/stats which should return stats of current logged in user. Like
{
"active_things": 23,
"last_login": "2017"
}
There is no id for this "resource" (it's not actually a resource, is it?). Backend just collects some "stats" for logged in user and returns an object of stats. There many endpoints like this in this application, for example, we have Notification center page where the user can change email addresses for different notifications.
So frontend app (single-page-app) first has to get current values and it sends the request to GET http://example.com/notification-settings.
{
"notifications_about_new_thing": "arunas#example.com",
"notification_about_other_thing": "arunas#example.com"
}
And there are many more endpoints like this. The problem is - how to return these responses in JSONAPI format? There is no ID in these endpoints.
And the biggest question is - why nobody else is facing this issue (at least I cannot find any discussion about this)? :D All APIs I ever made has some endpoints which don't have "id".
I have two ideas, first is to fake id, like "id": "doesnt_matter", the second - do not use json-api for these endpoints. But I don't like both of them.
Think RESTfully and everything can (must) be a resource. There is no "logged in" user as there are no sessions in RESTful APIs as they are stateless. There's no session state maintained between REST API invocations, so you have to be explicit about who the user is.
In this case, the resource is the user who has some stats attributes (in the simple case) or perhaps a relationship to a separate stats relationship (more complicated, not shown):
GET /users/1234
{
"data": {
"type": "users",
"id": "1234",
"attributes": {
"name": "etc.",
"active_things": 23,
"last_login": "2017"
}
}
}
I'm no JSON API expert- but it's worth noting that while JSON API is a concrete specification, it is not the same thing as JSON, nor as a REST API. If you don't like its semantics, I agree with commenters who argue, "Don't use it." If you are going to use JSON API, do so in a compliant way, where every response is a resource; every resource has an ID and a type; and additional information is supplied as attributes of the resource.
Toward your question, I'm thinking about something similar where my application returns computation results. Now on the one hand, these are not strictly "resources" and so I've been toying with the idea of returning the raw result as an array (which I believe would be valid JSON, with a caveat), e.g:
[ 47 ]
On the other hand, there is the idea that the results are the results of a computation that the client specified RESTfully, in which case one of the following two cases is likely true:
The same request submitted later is likely to have the same result. This suggests that in fact the result really is a resource.
The same request submitted later is likely to have a different result. This suggests that the client may want to track how results change for various queries, and so at least the query parameters should be part of the response.
In both cases, the response really is a 'result' object, and even though it doesn't have an ID per se, it does have an identity. If nothing else fits, the ID could be the query that generated the response.
This seems RESTful to me. User #n2ygk suggests that this is not correct as regards the JSON API spec, that an ID should simply be a unique ID and not have another semantic interpretation.
I'd love to hear other perspectives.
If I have an apiary.io API described like this:
### Create a User [POST]
+ Request (application/json; charset=utf-8)
{
"user_id": 1053,
"username": "demo#demo.com",
"email": "demo#demo.com",
"active": "true"
}
+ Response 201 (application/json)
{
"user_id": 1053,
"username": "demo#demo.com",
"email": "demo#demo.com",
"active": "true"
}
When I call it from my application and pass it data, it will always pass me back the described payload no matter what data I pass in.
Is there a way to get it to echo back the exact data that I passed in instead of the described payload?
According to Apiary docs/examples you can not, only static request-response mocking. Also you could track this issue.
If you want to use kind of advanced mocks I would suggest you wiremock. It's not so fancy, but way more feature reach. You could run it as a service and update mock mappings at runtime by sending HTTP requests.
Please check solution for your question using wiremock. Related documentation.
I have a node app that uses the Watson Conversation service. I am able to successfully trigger a call to another API via a dialogue node using the JSON that it uses for the reply. However after reading up it seems I am doing it wrong. I am triggering my client server to make a REST call by adding an action property to the context.
{
"context": {
"action": "lookup"
},
"output": {}
}
When I get my result I add it onto the context object and pass it back to the conversation service. This seems to work ok, but it causes some issues.
1) having to manually delete these props after I trigger the thing I want
2) In conversation I must wait for user input even though I am not actually requesting user input on the front end but rather my client app is sending a message with no input text and the results of the REST call on the context object. This message which is returned to the conversation at the node where the action was triggered is what triggers the child nodes. It seems like there is a standardized way IBM wants you to make these programmatic calls regardless of if it's to an IBM cloud function, or your own client app. https://console.bluemix.net/docs/services/conversation/dialog-actions.html#dialog-actions
docs method:
{
"context": {
"variable_name" : "variable_value"
},
"actions": [
{
"name":"<actionName>",
"type":"client | server",
"parameters": {
"<parameter_name>":"<parameter_value>",
"<parameter_name>":"<parameter_value>"
},
"result_variable": "<result_variable_name>",
"credentials": "<reference_to_credentials>"
}
],
"output": {
"text": "response text"
}
}
Is this a new feature? I was referencing sample projects for my own app and I didn't see this pattern. By using this format will it tell the parent node to wait for a response to come back before trying to process the children? Will it prevent me from needing to delete properties off the context object so that I'm not calling the same action over and over with the same parameters in further turns of the conversation?