I'm finding conflicting information on creating one time use deep links.
expire desktop_url generated through branch SDK after one time use
The documentation on "type" says "Must be an int. Set to 1 to limit deep link to a single use. Set to 2 to make the link show up under Quick Links while adding $marketing_title to data. Does not work with the Native SDKs." (https://docs.branch.io/links/integrate/)
I created a link using the included JSON with a POST to https://api2.branch.io/v1/url.
{
"branch_key": "*********************",
"data": {
"entityId": "282fd3da-5200-45f4-80a2-4f3a1c36bff6",
"$link_exp_date": 1567271700000
},
"type": 1,
"feature": "test_feature",
"tags": []
}
I expected the URL to be available for one time use. However I am able to successfully use the link multiple times until it expires. And retrieving the link using GET https://api.branch.io/v1/url doesn't return any properties that indicate the link was used.
Even before creating a deep link and testing, you need to integrate the Branch SDK in your respective app (Android, iOS etc).
The simple way to create a deep link is via dashboard and test this when the app is installed.
Related
I'm creating a script that goes into all tests into a test execution. I'd like to get the amount of defects for that particular test execution. Is that a way to get it using rest api?
Xray enables exporting Cucumber tests to be exported as .feature file that further can be used in your automated tests. To do so use this export endpoint
To import the automated test results back to Jira used this import endpoint
Usually APIs will be executed in conjunction with CI/CD tools, like Jenkins.
In this article you can see that the total number of defects can be view via the Jira UI.
And finally, this video shows how tests are imported and exported via the UI.
Tests can be created via API as well, see here.
I think it all depends on your testplans. When those contain all tests you should be able to execute the test via the endpoint rest/raven/1.0/api/testexec/<testExecution>.
Maybe it will be good to ask the very same question in the atlassian community.
Sorry for not being able to fully answer your question, but I think you now should have some things to read :)
There is one way that is more straightforward.
You can make use of the "Test Execution Defects" custom field, which is a calculated field.
Then you just need to use Jira's REST API and obtain information for the related Test Execution issue, for that specific custom field that returns an array. The number of elements corresponds to the number of defects.
Example of HTTP GET request:
https://sandbox.xpand-it.com/rest/api/2/issue/BOOK-31?fields=customfield_11802
Example of response:
{
"expand": "renderedFields,names,schema,operations,editmeta,changelog,versionedRepresentations",
"id": "20130",
"self": "https://sandbox.xpand-it.com/rest/api/2/issue/20130",
"key": "BOOK-31",
"fields": {
"customfield_11802": [
"20131"
]
}
}
Another way would be to use the JQL function "defectsCreatedDuringTestExecution ()", as mentioned here: https://docs.getxray.app/display/XRAY/Enhanced+querying+with+JQL
Then you could do a Jira REST API search call.
Example of HTTP GET search request using the JQL function:
https://sandbox.xpand-it.com/rest/api/2/search?jql=issue%20in%20defectsCreatedDuringTestExecution(BOOK-31)
I created a bunch of links through the API without specifying the type which defaults to 0. This doesn't make the links show on the dashboard under quick links. Now, I would like to make them show there but there doesn't seem to be an option to add a quick link, only create new. Given this, my idea was to use the API to read and update it however, update doesn't seem to allow passing argument type. Any hints on how to overcome this?
I have made a get request, retrieving the whole link details, copied the result, added the branch_key and branch_secret, changed type from 0 to 2 and sent an update request.
I've opened the link with ?debug=true but it doesn't seem to be a way to edit it to make it show on quick links either.
Response code was:
{
"error": {
"code": 400,
"message": "Invalid parameter: type"
}
}
As soon as I remove the type parameter, I get the proper link response with all the data.
The error that you saw is the expected behavior. The "type" key is reserved key and is not able to be changed once you created the link. You can manually set this only when you create the link using the API call. Please do reach out at integrations#branch.io if you have any further questions!
We store API created links and quick links in different DBs due to the volume of each type. This means that it's actually impossible to create a quick link through our public API or SDK. The only place would be from the dashboard. :( Hopefully, you understand our reasoning for doing it this way.
Currently, I am working in a FAQ bot, I have to include QnA pair each time when I get a new question related to the particular topic. Is it possible to revert to previous version if a particular QnA pair is not needed? This is the case, If I have added some hundred QnA pairs and I don't want it, Can I revert to previous version. From the QnA maker versioning its saying its not possible. As this is an earlier post, still that feature not present or in future there is a plan to include?
Also I know .tsv,.csv etc can be uploaded each time. Is there a provision to revert to previous version of QnA pair in QnA maker?
Short answer:
No, it has not changed since 2017. For plans to include it, I don't know, and there is no "iteration" or "version" in QnA Maker app.
Long answer:
But with some development, you can handle it.
You can see the list of API methods available for QnA Maker knowledge base management: https://westus.dev.cognitive.microsoft.com/docs/services/5a93fcf85b4ccd136866eb37/
In particular, you can focus on Update Knowledgebase method here: as you can see in its body sample, there is a delete block:
{
"add": {
"qnaList": [],
"urls": [],
"files": []
},
"delete": {
"ids": [
4,
13,
35
],
"sources": [
"Custom Editorial"
]
},
"update": { ... }
}
So you can use this method to "rollback" the entries that you added previously.
But be careful, because you have to use the id fields and they are not matching the id field used when you are using add.
Also I know .tsv,.csv etc can be uploaded each time. Is there a
provision to revert to previous version of QnA pair in QnA maker?
That may be a good option for quick rollback, if you save your KB every time before a modification, because you will not need to process the ID as mentioned above.
So i've been working on a REST api using express amd got most of the basics done. The current api I have does some simple GET, POST, PUT, DELETE and was able to populate a small client demo in both webapp and ios app.
But now I am trying to figure something out
Example:
/api/tvshow/
Returns a tv show object like:
[{
"Title": "Show title",
"Channel": "ABC",
"Started": "04/04/2012",
"Ended": "08/07/2015"
}]
Would it be possible to get 2 endpoints like
/api/tvshow/channels/
To get all channels in it's own list
/api/tvshow/channels/:channelName
To get all shows that are running on that channel all based from the main /api/tvshows/
Basically I would like for these to be populated automatically based on the current entries in the api.
Or would something like manually adding all these be better?
Let's assume that I have a resource called group with the following representation:
{
"id": 1,
"name": "Superheroes"
"_links": {
"self": {
"href": "http://my.api.com/groups/1"
}
}
}
Now let's say I want to create a new person instance by POSTing to /persons/1. Which of the following should I use for the request body:
Using ID
{
"name": "Batman",
"groupId": 1
}
Using link
{
"name": "Batman",
"group": "http://my.api.com/groups/1"
}
With the first method I access the id directly either to look up the related resource or eventually store the id in the database, when I persist the person instance. But with the other method, I either have to extract the id from the URI or, follow the link to load the related resource, and then find out its id. I really don't want to store the URI in the database.
With the latter option, seeing that the server controls the structure of the URI, is it fine for me to parse the id out of the link? Following the link back to the server itself seems odd, seeing that at this point we already have access to the information directly (we just need the id).
So to sum up, which of these options is best?
Use the id directly.
Use the link, but parse out the id.
Use the link, but access the link to get the resource instance, and then get the id.
TL;DR: Use simple ids.
More detailed explanation:
A straightforward approach is to create a person by POSTing to /groups/1/persons with a payload {"name": "Batman"}.
However, while such approach works for simple cases, the situation gets complicated if there are 2 resources that need to be referenced. Let's assume that a person also needs to belong to exactly one company:
GET /persons/1
{
"name": "Batman",
"group": 1, // Superheros, available at /groups/1
"company": 5 // Wayne Enterprises, available at /companies/5
}
Since there is no relationship between companies and groups, it is not semantically correct to create a person via POSTing to /groups/1/companies/5/persons or to /companies/5/groups/1/persons.
So let's assume you want to create a person with a request looking like this:
POST /persons
{
"name": "Batman"
"group": ???, // <--- What to put here?
"company": ??? // <--- What to put here?
}
Which brings us to the answer to your question:
Ease of use. Your API should be primarily designed for the ease of use. This is especially true, if you design a public API. Therefore, Option 2 (Use the link, but parse out the id) is out, since it imposes additional work for clients of your API.
Constructing search queries. If you want to be able to query persons which belong to the company 10 and the group 42, simple ids lead to more readable and less error-prone urls. Which of the following do you consider more readable?
URL with a simple id:
GET /groups/42?company=10
or URL with a url-encoded link:
GET /groups/42?company=http%3A%2F%2Fmy.api.com%2Fcompanies%2F10
I wouldn't underestimate the point of readability. How many times do you need to debug your API in various curls, logs, postmans, etc.
Development Links need to be parsed in the backend, while simple ids can be used directly. It's not about performance, but rather about additional work/tests you have to put in.
Endpoint maintenance. Imagine that your API endpoint evolves. You decide one day to switch to https or to include versioning in the url. This might break API clients, if they for some reason rely on structure of the links. Also, you might want to checkout if link parsing on your backend is done properly.
Argumentum ab auctoritate I know this is not a proper argument, but if you checkout APIs of large players, e.g. Twitter, Github or Stripe, they all use simple ids.
HATEOAS. One common argument in favour of links is that it is aligned with HATEOAS. However, as far as I know, this relates to additional links in API responses rather than using links in payloads of POST requests.
All in all, I would go for simple ids, since I haven't yet heard a compelling argument favouring links, which would beat the aforementioned.
You are missing two important things here.
You need a standard way to describe forms in the response, in this case your POST form.
The information about the group ids / uris, or how to get them has to be described in the form in a standard way.
For example a HTML FORM with a SELECT INPUT would be RESTful. The closest thing we got in json to do the same is json-ld and hydra. But if you are obsessed with hal, then use hyperagent forms or something like that. It will never be a standard, but if compatibility is not an issue, then it is good enough.
To answer your question, you should use the id, because the server knows how to interpret it. The client needs the resource identifiers, the server needs it only in the uri part of the request, not in the body.
From my experience, it is always best to go with the simplest solution for making requests.
The process of generating a new url and parsing it seems excessive to get a resource, whereas sending the id of the item you want seems much simpler.
Thus, I would send a request in the form:
{
"name": "Batman",
"group": 1
}