CKAN 2.9 datastore_search API - api

I am using CKAN 2.9 with python 3.8. I have my own ckan extension and now I want to change the search conditions from the datastore_search API. As an example if i search for "apple" my search result will also contain the query result of "banana" (condition: both are fruits). Now I have a few confusions after passing so many times with ckan:
In which folder of ckan I will get /api/3/action/datastore_search result logics(i have gone through ckan/logic/action but I can't see anything with datastore_search)
How can I extend and edit this file (datastore_search or datastore. I tried with example_idatastorebackend but it's not working)
Is it possible to call ckan datastore_search API within my ckan extension plugin file?

The datastore is a separate extension its code is all stored in ckan/ckanext/datastore with the api functionality stored in ckan/ckanext/datastore/logic/action.py
It is possible to write an extension that overrides the default datastore_search action. You just need to implement your action as you would any other custom action (IActions interface). You do however need to ensure your extension is loaded after the datastore otherwise the default functionality will supersede your method.
It isn't a current example, but you can check out ckanext-dataproxy for an example of an extension that does something similar to what you are suggesting.

Related

How to implement api versioning?

I have an web API application that will serve many clients at different times of release and now i need to implement a versioning. Because the API code will be constantly updated and API users will not be able to instantly change their API. Well, the standard situation is when you need to introduce versioning in general. I'm finding a way to organize it inside my API. It's clear that it will not be different folders with an application on the server, conditionally called app_v1, app_v2, app_v2.1, etc., cause this is duplication, redundancy and bad practise.
It's look like will be one application, and in the controllers at the code level there will be a division of the logic already, like If(client_version==1) do function1() else if(client_version==2) do function2(), etc. It seems that git supports tags, this is something similar to versioning, but because all supported versions of the application need be on the server at the same time, this is not about that. how i can realize an architecture in this case?
There are many well-known ways to use API versioning to make code work with older versions. (backward compatibility). The general purpose of API versioning is a way to make sure that different clients can use different versions of an API at the same time. I've seen several ways to do API versioning, such as:
URL Path Versioning: In this method, the number of the version is part of the API endpoint's URL path. For instance:
https://api.example.com/v1/assets
https://api.example.com/v2/assets
URL Query String Parameter: In this method, the version number is added to the API endpoint's URL as a query string parameter. For instance:
https://api.example.com/assets?version=1
https://api.example.com/assets?version=2
HTTP Header: In this method, the version number is put in an HTTP header, like the Accept-Version header. For instance:
Accept-Version: 1
Accept-Version: 2
If you are using dotnet for you project I would like recommend to standard library for that recommend to check this out. Or you can find solid materials in term of WebApi Versioning following link by #Steve Smith.
There is another answer.

TYPO3 - Insert api medipim

I want to call products on a web page via the api of Medipim. I have never done this before and I have never worked with TYPO3.
Therefore two questions.
In which (config) file do I place the authentication (I have an ID and secret key) and what exactly does that code look like?
When I want to call up the products, how do I use this in the TYPO3 page environment? Do I have to choose a html page or can I just enter it in the TYPO3 editor on a page?
Documentation: watch
You probably need an extension which converts the data you get from medipim to HTML. I Expect you get information as JSON, XML, or CSV.
As you won't publish your access code you probably will not use a javascript call from the browser to access the API, then you need some PHP.
Using PHP in TYPO3 is done in extensions. You should learn about building extensions in TYPO3. As a healper you might use the TYPO3 extension "Extension Builder" (=EB). As you have no local records you only need the extension frame with just one plugin from the EB.
Depending on your usage (will an editor select products from Medipim (option A) or should the visitor be able to select products (option B)?) you need a plugin with an option to insert desired product identification for BackEnd editors or just an input mask.
you can configure your plugin with typoscript so an integrator can enter the authentification information just once.
For option A you need to enhance your plugin with a field for the product ids.
keyword: flexform
for Option B you need a form.
Then you need to display the product information you get from the API. provide the returned data in variables and use Fluid templates to get a nice display.
Without any knowledge of TYPO3 this will be hard work and a lot to learn. The other possibility: hire an experienced TYPO3 developer and let him build this extension for you.

How to create a searchable central repository of code documentation using DocFx

I'm looking to create a central repository for all of our published API documentation using DocFx. I have documentation auto-generated via my build (using TFS) and published through my release (using Octopus) just fine for multiple individual sites. However, I'm wanting to pull it altogether in one location. The thinking is that through a parent site you could filter content in any of the individual sites without having to drill down into them. Do you have a recommendation on how to do this?
Also, within this same documentation repository I want to provide the capability to search by all of the meta data (project-level documentation) across the hundreds of projects in our portfolio. This will give our BA, DEV and QA teams easier access to what all our systems do. I like the "filtering" capability built into DocFx, but I'm wanting full-text search across all of the meta data. Do you have a recommendation for this functionality as well?
To change the location of the docfx output, edit the docfx.json file and specify the dest value. By default it is "dest": "_site". For more formatting guidance, reference: https://dotnet.github.io/docfx/tutorial/docfx.exe_user_manual.html.
Regarding full-text search, that is possible by simply ensuring the ExtractSearchIndex post-processor is invoked (in order to generate an index.json file of keywords) and that the global _enableSearch value is set to true in the docfx.json file. A snippet from that file would look like:
"postProcessors": [ "ExtractSearchIndex" ],
"globalMetadata": {
"_enableSearch": "true"
}
For your first question:
I think what you expect is like the .NET API Browser. The source code behind this page is not open to public, so you need create this page by yourself, through collecting xrefmap.yml from multiple sites, and extract the needed data into this page.
For your second question:
DocFX uses Luna to scan all the output files and generate an index file called index.json for later search use. In your case, you should want to limit the search scope only in the metadata you defined. This is also not supported by DocFX by default. You can also use Luna in your central place to search these meta. You can create your specific index.json for each project first, and the cental place to collect them for the search page.

Running Parameters Against an OpenShift Template Through the API

I'm developing a custom interface which will integrate with OpenShift Origins. At the moment, I have templates which I wish to instantiate. I know I can do this by running the template against the /processtemplate end-point. However, the only way I can find for setting the template parameters is to iterate through the parameter list and overwrite the fields manually.
Is it possible to send a parameter list, and have OpenShift run it against the template, or is this the only solution?
We do not have something like that today - it might be exposed in the future via a /templates/foo/process endpoint supporting form post, but we were hesitant in case we wanted to expose more complicated parameter values in the future.

wso2: how to remove the version number from the url path

I'm quite new to WSO2. Although I managed to find a quick hack to ignore the version number from the url path when calling my services, I would like to know if there's an efficient way of doing this: /Personal/1.0.0/Members?tenantId=1&entityNumber=1
Make that API with default version in the Implementation Tab by checking "Make this default version" checkbox. Check here for more and the below image for how to do it.
Once you have checked that "Make this default version" option, You can two URLs for the API in the Store like below
A default API can be invoked without specifying the version number in
the URL. For example, if you mark http://host:port/youtube/2.0 as the
default version when the API has 1.0 and 3.0 versions as well,
requests made to http://host:port/youtube/ get automatically routed to
version 2.0.
If you mark any version of an API as the default, you get two API URLs
in its Overview page in the API Store. One URL is with the version and
the other is without. You can invoke a default version using both
URLs.
From APIM 1.9.0 onwards there is a new feature introduced as "version strategy" where you can provide {version} tag in the context in any place. As an example, if you provide the context as api/{version}/test and in the version field as 1.0.0v it will replace the URL pattern as api/1.0.0/test.
Same like that if you really need to get rid of version number apart from the above answer you can provide a text in the version field since it allows text as well.
E.g.,
In context -> api/{version}/test and in version -> text will make the url pattern as api/text/test
But please note this is not recommended since version is supposed to use version number. You can use the default url as explained in Abiraman's answer. But since version field number allows numeric and text for a situation like -> 1.0.0v, 1v, 1.0.b you can try this as well.