I am creating a lot of spaces by REST API and I would like to assign them a category, too. However I couldn't find the parameter to do so.
My Rest API
POST /rest/api/space
{"key":"LinuxSpace",
"name":"Linux Team",
"description": {
"plain": {
"value": "this Is A Test",
}
}
}}
This will create the space but couldn't find a way to add a label to the space, couldn't find it anywere in the documentation.
I'm using Confluence 6.15.10
Related
I am trying to create events via the MS Graph API (with Powershell but using the REST API).
So far I can create events without problems. All the properties I want to set are correctly set - except I don't seem to manage to set the IcalUId - as I cannot find such created events via
"/users/$UPNofMBX/calendar/events?`$filter=iCalUId eq '$appointment_UID'"
($Appointment_UID = the desired identifier for later finding the event - It is coming from an external - commercial solution)
If I import via Outlook an ICS file with a specific value in the "UID:" field, the above Graph query finds the event which carries the searched for value in the ICalUId field.
If I set it at creation time via graph with the below body, the above search query line does not find the event.
The body of the REST call looks like this:
$Body = #"
{
"subject": "$appointment_Subject",
"iCalUId": "$appointment_uid",
"body": {
"contentType": "HTML",
"content": "$appointment_Body"
},
"start": {
"dateTime": "$appointment_Time_Start",
"timeZone": "Europe/Berlin"
},
"end": {
"dateTime": "$appointment_Time_End",
"timeZone": "Europe/Berlin"
},
"location":{
"displayName":"$appointment_Location"
},
"attendees": [
{
"emailAddress": {
"address":"$UPNofMBX",
"name": "Ressource"
},
"type": "required"
}
],
"allowNewTimeProposals": false,
"transactionId":"$(New-Guid)"
}
Unfortunately, in none of the examples # Microsoft is the use of the ICalId explained when creating an event. Also I didn't find any examples on the net.
Hint: If I use Microsoft.Exchange.WebServices.Data within a C# app, I can set the iCalUId.
The goal is to set a reference UID / ID / anything in the to-be-created event so that I can find this event later via this reference in order to update or delete it. The only reference information I have is the UID (iCalUId) from an (update/delete) ICS file from the external commercial solution.
I would prefer to not build a translation table between the UIDs from the commercial solution when they arrive via ICS and the IDs of the newly created events when they are given back in the REST call # creation time so I can find them later if necessary.
Any insight what I am doing wrong or a solution is greatly appreciated.
I have setup a custom dimension in google analytics 'dimension2' into which I want to capture a WPForms UniqueID. I added this to Google Tag manager and I can see the custom dimension with a value when I preview site in GTA preview.
. I added this to gtags.js on this word press site,
var dimensionValue = $.cookie("_wpfuuid");
gtag('config', 'UA-1234567890-2', {
'custom_map': {'dimension2': 'wpfid'}
});
gtag('set', 'dimension2', {'wpfid': dimensionValue});
In google analytics query explorer, I can see dimension2 in the test results.
"columnHeaders": [
{
"name": "ga:dimension2",
"columnType": "DIMENSION",
"dataType": "STRING"
},
{
"name": "ga:users",
"columnType": "METRIC",
"dataType": "INTEGER"
}
],
"totalsForAllResults": {
"ga:users": "1"
},
"rows": [
[
"40502794-ecf1-4cf6-97b9-2c16c7f6c949",
"1"
]
]
And, I can see the dimension2 data in google analytics user explorer, so it is making it to the browser interface for analytics.
However, when I add the following to my API query script, it breaks and is not generating any php errors, or the error is that it does not recognize 'dimension2'. I tried this on 2 views and both act the same. Here is my code to add the custom dimension to my query
$dimension = new Google_Service_AnalyticsReporting_Dimension();
$dimension->setName("ga:dimension2");
What am I missing? Why isn't this visible in google api results and/or where I can I see any errors?
Some hours later, this code started to work, which suggests to me that custom dimensions are not immediately available to the api. In this case the api recognized dimension2 long after the data was visible in the analytics website.
Second possibility to check which can cause this seemingly good code to not work, you are using the wrong view id. Of the 2 views I tested, this only works on one.
I am considering two approaches when updating rest api and i am not sure how to choose which approach to follow
For example
GET /service/1000
{
"service_id": 1000,
"name": "Some service"
"status": "ACTIVE"
}
Now If I want to update this service I could do
PUT /service/1000
{
"service_id": 1000,
"name": "Some service"
"status": "INACTIVE"
}
or
POST /service/1000/update-status
{
"status": "INACTIVE"
}
or even
POST /service/1000/activate
{
}
and
POST /service/1000/deactivate
{
}
So my question is what is the rule of thumb to follow when choosing approach how to update REST?
EDIT
This question is not about when to use POST/PATCH/PUT, it is about should resource be update calling the same resource, or should it be updated using an action. For example, twitter uses actions https://developer.twitter.com/en/docs/api-reference-index
From what you are considering put is more appropriate however I in some cases patch is more appropriate so when you are changing the value of resources you consider using patch but when you are adding a new property put is more appropriate see---
REST API PATCH or PUT
The Watson Dialog Service on IBM Bluemix allows to create profile variables and to pass values to them. In the examples these variables always seem to have the type "TEXT" (see "myVariable" below). Are there any other types available? How would I pass a JSON object and how would I access specific values inside a dialog?
<variables>
<var_folder name="Home">
<var name="myVariable" type="TEXT"/>
</var_folder>
</variables>
I talked with the service team, and the recommendation is to use the new Watson Conversation service as it is actually possible to pass an array of name:value pairs. Below is a sample that the team came up with on the fly. Hopefully it's helpful.
Sample:
{
"client_id": 4435,
"name_values": [
{
"name": "string",
"value": "string"
}
]
}
For example, if you want to post to a context variable named JSON_object, the PUT context payload would be:
{
"client_id": 4435,
"name_values": [
{
"name": "JSON_object",
"value": "{"sample":"data"}"
}
]
}
HOWEVER, they highly recommend converting the JSON to flat XML before posting as context, since dialog has much more versatility to parse XML, using {variable_name.xmlElementName}.
More info found on the API explorer - https://watson-api-explorer.mybluemix.net/apis/dialog-v1#!/Profile/setProfile under PUT CONTEXT method.
Best to go to the documentation.
variables can be objects - consisting of many vars
http://www.ibm.com/watson/developercloud/doc/dialog/reference_elements.shtml#reference_variables
vars can be of types
http://www.ibm.com/watson/developercloud/doc/dialog/reference_elements.shtml#reference_var
If I wanted to create (POST) a new resource linking two independent resources, what is the most proper - with respect to HATEOAS and REST principles - way to structure the entity of the request?
Any references in RFCs, W3C documents, Fielding's thesis, etc., about the proper way for a client to request two independent resources be linked together would be most valuable. Or, if what I'm interested in is simply outside the scope of REST, HATEOAS, an explanation of why would also be great.
Hopefully my question above is clear. If not, here's a scenario and some background to ground the question.
Let's say I have two independent resources: /customer and /item, and a third resource /order intended to the two.
If I'm representing these resource to the client in a HATEOAS-like way (say with JSON-LD), a customer might (minimally) look like:
{
"#id": "http://api.example.com/customer/1"
}
and similarly an item like:
{
"#id": "http://api.example.com/item/1"
}
I'm more concerned about what scheme the entity of the POST request should have, rather than the URL I'm addressing the request to. Assuming I'm addressing the request to /order, would POSTing the following run afoul of HATEOAS and REST principles in any way?
{
"customer": {"#id": "http://api.example.com/customer/1"},
"item": {"#id": "http://api.example.com/item/1"}
}
To me, this seems intuitively OK. However, I can't find much or any discussion of the right way to link two independent resources with a POST. I discovered the LINK and UNLINK HTTP methods, but these seem inappropriate for a public API.
The client does not build URIs, so this is wrong unless these resource identifiers or at least their template came from the service. It is okay to use the id numbers instead of the URIs until you describe this in the response which contains the POST link.
An example from the hydra documentation:
{
"#context": "http://www.w3.org/ns/hydra/context.jsonld",
"#id": "http://api.example.com/doc/#comments",
"#type": "Link",
"title": "Comments",
"description": "A link to comments with an operation to create a new comment.",
"supportedOperation": [
{
"#type": "CreateResourceOperation",
"title": "Creates a new comment",
"method": "POST",
"expects": "http://api.example.com/doc/#Comment",
"returns": "http://api.example.com/doc/#Comment",
"possibleStatus": [
... Statuses that should be expected and handled properly ...
]
}
]
}
The "http://api.example.com/doc/#Comment" contains the property descriptions.
{
"#context": "http://www.w3.org/ns/hydra/context.jsonld",
"#id": "http://api.example.com/doc/#Comment",
"#type": "Class",
"title": "The name of the class",
"description": "A short description of the class.",
"supportedProperty": [
... Properties known to be supported by the class ...
{
"#type": "SupportedProperty",
"property": "#property", // The property
"required": true, // Is the property required in a request to be valid?
"readable": false, // Can the client retrieve the property's value?
"writeable": true // Can the client change the property's value?
}
]
}
A supported property can have an rdfs:range, which describes the value constraints. This is not yet (2015.10.22.) added to the hydra vocab as far as I can tell, but I don't have time to follow the project. I think you still can use the rdfs:range instead of waiting for a hydra range.
So in your case you could add an item property with a range of http://api.example.com/doc/#Item and so on. I assume you could add the links of the alternatives, something like http://api.example.com/items/, so you could generate a select input box. Be aware that this technology is not stable yet.
So you can send a simple JSON as POST body {item: {id:1}, customer: {id:1}} or something like that, which you generate based on the POST link. The RDF is for the client not for the server. The server can understand the data structure it requires, it does not need RDF. You don't need a dictionary to understand yourself...