How can we use Search Rest API for custom attribute value

Akshay_Patil

Hello Experts,

We want to download/ brows documents from CS(Version 16.0.4) in third party application based on some metadata search.

I was exploring CS Search REST API "GET API/V1/Regions" but there is no example i found in KB using this API.

Also i found below url based API:

https://<CS HOst>:Port/OTCS/llisapi.dll?func=search&where1=("Attr_1016429_2":"US"and"Attr_1016429_3":"EN")&where2=(OTLocation:1016421&outputformat=xml

Can some one please clear my doubt what is the difference between these two? and which is the better approach for my requirement.

Thanks,

Akshay

Appu Nair

Your second example is the more mature of the two. Livelink has had search XML API later renamed to just Search API (?func=search)for years and it is the preferred way old integrations worked

if you look at the date of this posting https://www.tek-tips.com/faqs.cfm?fid=3552 I bet it is David Templeton in 2003

What does the new REST API offer?

• Simplifies usage for mobile devices and other modern JS-based solutions.extremely compact and minified frameworks . Here the static framework execution environment that runs in your browser/ device is doing all that work . It just needs data as part of a JSON query .This are most eligible for Single Page Applications ( SPA’s) includes proper UI design rules and such like . No more pop up screens like old style JS.

If I were doing this what I would look is

• Livelink will not show any data until the caller is identified as a user in its database or a man-in-the-middle application. To this end, OT changed the search API before the advent of the REST API to actually read a header ticket(you will hear OTDSTicket, OTCSTicket, etc in a lot of conversations, at the end to Livelink there are one or two Cookies on your browser LLCookie for classic UI operations so for all practical purposes the Search API will behave like a classic UI page, so long as it can trust the LLCookie.In REST deliberately it will not trust the cookie simply because REST APIs are intended to be called by SPA's like SmartUI. It will always look for basic authentication or a header value (our OTCSTicket/OTDSTicket).REST is probably better in the future as its API is always evolving.RESt has a convenient ticket refreshing mechanism so your code is almost always going to be not rejected :)
• If you can compare see if the search API all the possibilities are implemented vis-à-vis commands and methods, say if you want to derive a no hardcoded solution involving search fields, display parameters and such like and able to run a template, I bet the old API has ways to just run a search template. Check if the same is ported in REST.
• WR has simple search integrations with which beautiful features can be exploited like the WR RUN SERVICE does it work with the rest of API...

MY $0.02