I have a working QnA Maker instance, I manually added a few URLs to public websites.
Now I want to add many more URLs. I guess this means mastering the REST API? What method should I call? Any examples to start from?
I found this sample, which got me started:
https://learn.microsoft.com/en-us/azure/cognitive-services/QnAMaker/quickstarts/create-new-kb-python
It's an example of calling the REST API's "Knowledgebase - Create" operation.
https://learn.microsoft.com/en-us/rest/api/cognitiveservices/qnamaker/knowledgebase/create
It crashes if you add more than 10 URLs. Eventually, I found there are limits of 10 URLs on create.
Adding more requires a separate REST call - "Knowledgebase - Update" with an "add" node in the request body.
https://learn.microsoft.com/en-us/rest/api/cognitiveservices/qnamaker/knowledgebase/update
I think this is limited to 5 URLs per call. I extended the python code to loop over my list of URLs and "add" them all. It seems to work but gets slower and slower to complete each call. My guess is QnA Maker re-runs some internal indexing logic over the whole knowledge base on every update call? If so then that limit per call is probably counter-productive.
Related
We need to develop an API which takes a CSV file as an input and persists them in database. Using vertical slicing we have split the reuirement into 2 stories
First story has partial implementation with no data validation
Second story completes the usecase by adding all validations.
Sprint-1 has first story and sprint-2 has second. After imlemneting first story in sprint-1 we want to release it to production. However, we dont want to make the API accessible to public which would be big security risk as invalid data could be inserted into database (story1 ignores validation)
What is the best strategy to release story1 at the end of sprint1 while addressing such security concerns?
We tried disbling the access via toggle flag such as ConfigCat. However, we dont want to implment something which is not required for actual implementation
is there really such a risk that in 1 sprint, someone may start using the API? And if you haven't added it to any documentation, how would they know of it's existance?
But let's say it is possible - what about using a feature toggle? When the toggle is activated, the end point spits out null or even a HTTP error code. Then you can enable to feature toggle when you're ready for people to start using the endpoint.
In the roblox api documentation (not to be confused with roblox's lua documentation) there is an argument for some GET request operations, for example https://inventory.roblox.com/v2/users/2333/inventory?assetTypes=Model&cursor=idk&limit=10&sortOrder=Asc . What are the cursors/how do they work?
I'm making a huge project that'll make using the roblox api way easier, but I dont know the cursors so there is a lot less I can do.
Roblox api documentation here
This is a concept called pagination. Pagination is when a website is split up into different pages. This helps Roblox and other websites not give back an unnecessary amount of information.
Once you send a request to Roblox which may return more than whatever limit you have specified entries you will get a cursor value. You can then send another request with that cursor value you were just given to get the next page of values.
I'm creating a set of RESTful API and I have this question: I have a resource that has some images attached and I'm creating my resources like this:
POST to /resource: create the object and save the images to the server.
GET to /resource returns the object but no the images, GET to /images returns the images.
My question is: is this compliant with REST or should I either make the resources completely separate or completely unified?
I choose this solution because when posting I for sure send the images, but I may need them or not when doing a get.
is this compliant with REST
It's fine - for instance, if you look at the way that Atom Publishing works, you'll see that when you post a media to a collection, two resources are created (the Media Resource and the Media Link Entry).
However, fine here means you are making tradeoffs. In particular, cache invalidation is more challenging when you a POST to one resource may change the representation of a different resource.
HTTP caching semantics are optimized for the common case, which is that a given request changes only the target resource; no spooky action at a distance.
That doesn't mean that this is the Right Way, but rather that you should understand that this is the way that HTTP makes easy, and in other cases you need to pay attention to the details.
POST can basically mean anything, and unlike PUT and GET (for which there is a bit more of a direct relation), POST is allowed to result in all kinds of side-effects, including the creation of 0 or more resources.
POST is basically the 'anything goes' method.
Here is an excerpt from an assignment I am currently doing:
Build a dummy app that:
Contains a REST API that operates over a single resource.
Contains a Backbone client that consumes that API and can list, show, create, update, and remove that resource.
My understanding was that the term "consume" implies total coverage of the API's exposed ressources. However, the assignment says "consumes that API and can [CRUD] that resource".
Is that sentence redundant or is my understanding of the term wrong?
(Bonus question: why searching Google for this question returns countless language-specific tutorials for "consuming an API" but none explain what the term actually means?).
To consume an API means to basically use any part of it from your application.
Consuming an API here means creating a client which can send requests to the API that you build.
It appears that you need to create and API which can handle Create, retrieve, update and delete (CRUD) of a resource. For instance if your REST api is to create a blog, your API should handle CRUD functions for the object/resource blogpost.
POST - Create a blog post
GET - Retrieve a blog post
PUT - Update a blog post
DELETE - Delete a blog post.
It is about the direction of the app's interaction with API - it either provides an API, or consumes it, so there are providers and consumers of API, and this is just a less general and ambiguous term than 'using'.
Simply consuming an API means using it in your application.
For, e.g., GET request to https://someapi/Users will give you all the users.
You need to request this URL https://someapi/Users to get all the users and then you can use it into your application.
I always think about Albert Einstein's quote of "If you can’t explain it to a six year old, you don’t understand it yourself." when someone asks a question that you might take for granted due to technical experience you have on a subject.
I think the following medium.com article does an excellent job explaining it: How do you explain API to a 5-year-old?
simply means : using the API.
You can do it with HTTP method (GET, POST, PUT, DELETE..) using something like Postman (Tool) or maybe you have a client app/library that calls these methods implicitly.
You've probably all seen the maps.google.com.au address lookup. Start typing into the text box and your address auto completes in the list before you've finished. It also bolds the matching sections of the text that link to what you are typing.
I've used both the javascript api of maps and the http api. The geocoding seems to do something decent with the matches but i'm not entirely sure how one would go about getting this to work.
Anyway have a tutorial or a quick five step process that they would recommend I follow to get this feature going?
The feature you are looking for is "find as you type" or "suggest as you type" or AJAX live search.
To get the functionality via the Maps API is possible as any other find as you type solution. For each key entered into your search box you already send the request to the server and see what matches the entered text so far. The problem is that you can only send so many requests to google before you get a 620 (too many requests) error. Having a find-as-you-type mechanism is usually easier when you have your own small DB which you can query, that is faster and you won't have problems with too many requests.
Some links with tutorials:
Javascript Autocomplete Combobox - find as you type
Suggest as you type
AJAX Live Search