I'm using GSA (version 6.14) and we would like to get an auto suggest function on our website. Works fine for basic requests, but it seems the GSA offers more functionality when you would be using user-added results. However, I can find nowhere a reference on how to add user-added results.
This is what the information tells me today :
/suggest?q=<query>&max=<num>&site=<collection>&client=<frontend>&access=p&format=rich
should return a response as below :
{
"query": "<query>",
"results": [
{ "name": "<term 1>", "type": "suggest"},
{ "name": "<term 2>", "type": "suggest"},
{ "name": "<term 3>", "type": "uar", "content": "Title of UAR",
"moreDetailsUrl": "URL of UAR"}
]
}
I am able to get results as the first 2 lines, but would like to get results as the last line also, so with content and a moreDetailsUrl. So maybe a very stupid question but I am not able to find the answer anywhere : How and where do I add this UAR ?
I actually want to understand if it's feasible to get metadata into the content part of the JSON, so if for instance an icon meta is available I'd like to have it included in the JSON so I can enrich my search results.
User Added Results are a OneBox that can be added to multiple frontends. See this: https://developers.google.com/search-appliance/documentation/614/admin_searchexp/ce_improving_search#uar
When done with Suggest, the data is fed from user entering 'keymatches' directly. What's different about them is that they are a direct link versus a suggested query. If you use the out of the box experience, you'll click a link to the url instead of running another query.
Related
My use case is to hit endpoint 1 from my API which returns a list of jsons and take the id from each json list and hit endpoint 2 with that and later validate
Endpoint 1 get returns list of jsons like below:
[
{
"id": 123,
"name": "test1",
"value": "uk123"
},
{
"id": 143,
"name": "test2",
"value": "us143"
}...
]
My scenario is:
Scenario: test
Given path "\endpoint1"
When method get
Then status 200
* def res = response
Given path "\endpoint2"
And param {"id": pass-each-id-from-above-response-list-one-at-a-time}
When method get
Then status 200
Then match response.id = (use-above-passed-each-id-from-above-response-list-for-validation)
Is there a possibility for writing this workflow using karate?
Sorry for posting this again, as I mistakenly removed the post. I did go through your documentation about call method available, but I was unable to find something which does this as part of the same feature file and not calling it from an another feature file. So posting it again.
Sorry again for causing inconvenience, if I have missed anything.
I am learning this tool and this tool had helped me resolve many of my API testing requirements.
Thank you!
Use the link
https://github.com/intuit/karate#data-driven-features
It has tje example you can use
I am writing a new invoice with one line item into Xero. It works fine, except that the Tracking Category is not being set.
I am following the instructions here:
https://developer.xero.com/documentation/api/invoices#post
And below is part of the JSON being sent. All properties except tracking is being filled in. The tracking data comes from loaded TrackingCategories, so it is definitely correct.
"LineItems": [{
"Description": "test",
"LineAmount": 123.45,
"Tracking": [{
"TrackingCategoryID": "8990282b-63b6-459c-ab3b-cf7b8ff08bbc",
"Name": "Project",
"OptionName": "C17212 - 11 Boas Avenue, Joondalup"
}],
"Quantity": 1.0
}]
Any ideas on what may be wrong with my PUT request? Everything except tracking is working.
Got it. The documentation about the POST says to set "OptionName", but if you look at the examples on the side it shows "Option". And "Option" is the one that works.
Here is the written documentation:
And here is the example on the right side of the page:
Using Azure Search REST API v2016-09-01, the following query find the expected document:
?queryType=full&search=id:3119443 AND name:du*
{
"value": [
{
"#search.score": 4.425995,
"id": "3119443",
"name": "dupond"
}
]
}
Whereas the following broader query (searching d* instead of du*) does not find the same document:
?queryType=full&search=id:3119443 AND name:d*
{
"value": []
}
The name field uses a custom analyzer with the Whitespace tokenizer and the WordDelimiterTokenFilter, AsciiFoldingTokenFilter and Lowercase token filters.
Most of the indexed documents are correctly found when searching their first name letter.
The issue is 100% reproducible on those specific documents, for which I don't find anything special.
The Search Service is a "Standard" tier (1 replica, 1 partition, 1 search unit), with the index containing 3,000,000+ documents.
Thank you.
Thanks for reporting the issue. As commented, this is a regression introduced in a recent change. The bug has been fixed. Thanks.
I am using the Gmail API in Google Apps Script (which is basically Javascript), and I need to make as few calls to the API as possible, for efficiency and speed.
I'm using Users.messages: list to list the messages in a user's mailbox, and the response includes an array called messages, and for each message it includes an id and a threadId, like so:
"messages": [
{
"id": "152b93b1111c33e2",
"threadId": "152b922266c33e2"
},
{
"id": "152b93338c98cb3",
"threadId": "152b922266c33e2"
} ...
But I need the response to include more information about each message, so that I don't have to make a separate Users.messages:get call for each message.
The APIs Explorer on the Users.messages: list page says you can use the fields parameter to "specify which fields to include in a partial response."
When I click "Use fields editor" to select the three items I need, it fills the following in to the field:
messages(id,internalDate,payload)
Then when I execute the command, it shows that the GET command should look like this:
https://www.googleapis.com/gmail/v1/users/test#test.com/messages?fields=messages(id%2CinternalDate%2Cpayload)&key={YOUR_API_KEY}
However, the messages array in the results does not include the internalDate or the payload fields. It just includes the message id only, like so:
"messages": [
{
"id": "152b93b1111c33e2"
},
{
"id": "152b93338c98cb3"
} ...
It also does not include the threadId anymore, but it DOES continue to include the threadId if I select that as one of the fields, like so:
messages(id,threadId)
and the URL looks like this...
https://www.googleapis.com/gmail/v1/users/test#test.com/messages?fields=messages(id%2CthreadId)&key={YOUR_API_KEY}
And the result looks exactly like the first result above, where we weren't using the fields parameter.
So I know the fields parameter is actually doing something.
Thinking this might just be a limitation of the APIs Explorer, I tried making the API call in Google Apps script, but it still does not include the fields I need.
You are almost there.
When listing messages, theid and threadId of each message is all you get. You then have to get each message separately.
If you e.g. just want the internalDate of the message, it is in this request it should be specified in the fields parameter.
Request
GET https://www.googleapis.com/gmail/v1/users/me/messages/152b792a91c9c391?fields=internalDate&key={YOUR_API_KEY}
Response
{
"internalDate": "1454778787000"
}
I've been creating a RESTful application and am undecided over how I should handle requests that don't return all entities of a resource or return multiple resources (a GET /resource/all request). Please allow me a few moments to setup the situation (I'll try to generalize this as much as possible so it can apply to others besides me):
Let's say I'm creating a product API. For simplicity, let's say it returns JSON (after the proper accept headers are sent). Products can be accessed at /product/[id]. Products have reviews which can be accessed at /products/[id]/review/[id].
My first question lies in this sub-resource pattern. Since you may not always want the reviews when you GET a product, they are accessible by another URI. From what I read I should include the URI of the request that will return all review URI's for a product in the response for a product request. How should I go about this so that it abides to RESTful standards? Should it be a header like Reviews-URI: /product/123/review/all or should I include the URL in the response body like so:
{ 'name': 'Shamwow',
'price': '$14.99',
'reviews': '/product/123/review/all'
}
My second question is about how the /product/[id]/review/all request should function. I've heard that I should just send the URL's of all of the reviews and make the user GET each of them instead of packaging all of them into one request. How should I indicate this array of review URIs according to RESTful standards? Should I use a header or list the URIs in the response body like so:
{ 'reviews': [ '/product/123/review/1',
'/product/123/review/2',
'/product/123/review/3'
]
}
Your problem is you're not using Hypermedia. Hypermedia specifically has elements that hold links to other things.
You should consider HAL, as this is a Hypermedia content type that happens to also be in JSON.
Then you can leverage the links within HAL to provide references to your reviews.
As to your first question (header or body), definitely do not invent your own custom header. Some here will argue that you should use the Link header, but I think you'll find plenty of need for nested links and should keep them in the body.
How you indicate either the URI to the reviews/ resource, or the list of URI's within that, is entirely up to the media type you select to represent each resource. If you're using HTML, for example, you can use an anchor tag. If you're using plain JSON, which has no hypermedia syntax, you'll have to spend some time in the documentation for your API describing which values are URI's, either by nominating them with special keys, or wrapping them in special syntax like {"link": "reviews/123"}, or with a related schema document.
Take a look at Shoji, a JSON-based media type which was designed explicitly for this pattern of subresources.
The JSON Schema standard might help you here, in particular Hyper-Schemas.
It lets you define how to extract link URIs from your data, and what their "rel"s are - essentially turning your JSON data into hyper-media. So for your first bit of data, you might write a schema like:
{
"title": "Product",
"type": "object",
"properties": {...},
"links": [
{"rel": "reviews", "href": "{reviews}"}
]
}
The value of href is a URI Template - so for example, if your data included productId, then you could replace the value of href with "/product/{productId}/review/all".
For the second bit of example data (the list of reviews) you might have a schema like this:
{
"type": "object",
"properties": {
"reviews": {
"type": "array",
"items": {
"links": [
{"rel": "full", "href": "{$}"}
]
}
}
}
}
In the URI Template of href, the special value of {$} means "the value of the JSON node itself". So that Hyper-Schema specifies that each item in the reviews array should be replaced with the data at the specified URL (rel="full").