वेब सेवाएँ¶
Koha provides a number of APIs allowing access to it's data and functions.
OAI-PMH¶
मेटाडाटा कटाई के लिए ओपन अभिलेखागार पहल प्रोटोकॉल (OAI-PMH) के लिए 'प्रतिभागियों' के दो समूह हैं: डेटा प्रदाता और सेवा प्रदाता। डेटा प्रदाता (खुला अभिलेखागार, खजाने) मेटाडाटा के लिए स्वतंत्र पहुँच प्रदान करते हैं, और हो सकता है, लेकिन जरूरी नहीं है, पूर्ण ग्रंथों या अन्य संसाधनों के लिए स्वतंत्र पहुँच प्रदान करते हैं। OAI-PMH को लागू करने के लिए डेटा प्रदाताओं के लिए, कम बाधा समाधान के लिए एक आसान प्रदान करता है। सेवा प्रदाता फसल और दुकान मेटाडाटा के लिए डेटा प्रदाताओं की OAI इंटरफेस का उपयोग करें। नोट: यह मतलब है कि डेटा प्रदाता के लिए कोई लाइव खोज अनुरोधों देखते हैं कि; बल्कि, सेवाओं OAI-PMH के माध्यम से काटा डेटा के आधार पर कर रहे हैं.
वर्तमान में कोहा केवल डेटा प्रदाता के रूप में कार्य कर सकता है। यह अन्य भंडारों से फसल नहीं कर सकता है। अन्य भंडारों से कोहा फसल होने का सबसे बड़ा ठोकर ब्लॉक यह है कि एमएआरसी एकमात्र मेटाडाटा प्रारूप है जो कोहा इंडेक्स मूल रूप से है। OAI-PMH कैसे काम करता है के आरेखों के लिए http://www.oaforum.org/tutorial/english/page3.htm पर जाएं।
By default Koha won't include item information in OAI-PMH result sets, but they can be added by using the include_items option in the a configuration file linked from OAI-PMH:ConfFile.
ओएआई-पीएमएच के बारे में और जानें: http://www.openarchives.org/pmh/
कोहा में ओएआई-पीएमएच को सक्षम करने के लिए इसे संपादित करें :ref:`ओएआई-पीएमएच' वरीयता। एक बार सक्षम होने पर आप अपनी फ़ाइल देखने के लिए http: //YOURKOHACATALOG/cgi-bin/koha/oai.pl पर जा सकते हैं।
नमूना ओएआई Conf फ़ाइल¶
format:
vs:
metadataPrefix: vs
metadataNamespace: http://veryspecial.tamil.fr/vs/format-pivot/1.1/vs
schema: http://veryspecial.tamil.fr/vs/format-pivot/1.1/vs.xsd
xsl_file: /usr/local/koha/xslt/vs.xsl
marcxml:
metadataPrefix: marxml
metadataNamespace: http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim
schema: http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd
include_items: 1
oai_dc:
metadataPrefix: oai_dc
metadataNamespace: http://www.openarchives.org/OAI/2.0/oai_dc/
schema: http://www.openarchives.org/OAI/2.0/oai_dc.xsd
xsl_file: /usr/local/koha/koha-tmpl/intranet-tmpl/xslt/UNIMARCslim2OAIDC.xsl
SRU server¶
कोहा यूआरएल (एसआरयू) प्रोटोकॉल के माध्यम से खोज / पुनर्प्राप्ति लागू करता है। प्रोटोकॉल के बारे में अधिक जानकारी http://www.loc.gov/standards/sru/ पर मिल सकती है। लागू संस्करण संस्करण 1.1 है।
योजनाएँ¶
If you want to have information about the implementation of SRU on a given server, you should have access to the Explain file using a request to the server without any parameter. Like http://myserver.com:9999/biblios/. The response from the server is an XML file that should look like the following and will give you information about the default settings of the SRU server.
<zs:explainResponse>
<zs:version>1.1</zs:version>
<zs:record>
<zs:recordSchema>http://explain.z3950.org/dtd/2.0/</zs:recordSchema>
<zs:recordPacking>xml</zs:recordPacking>
<zs:recordData>
<explain xml:base="zebradb/explain-biblios.xml">
<!--
try stylesheet url: http://./?stylesheet=docpath/sru2.xsl
-->
<serverInfo protocol="SRW/SRU/Z39.50">
<host>biblibre</host>
<port>9999</port>
<database>biblios</database>
</serverInfo>
<databaseInfo>
<title lang="en" primary="true">Koha 3 Bibliographic SRU/SRW/Z39.50 server</title>
<description lang="en" primary="true">Koha 3 Bibliographic Server</description>
<links>
<sru>http://biblibre:9999</sru>
</links>
</databaseInfo>
<indexInfo>
<set name="cql" identifier="info:srw/cql-context-set/1/cql-v1.1">
<title>CQL Standard Set</title>
</set>
<index search="true" scan="true" sort="false">
<title lang="en">CQL Server Choice</title>
<map>
<name set="cql">serverChoice</name>
</map>
<map>
<attr type="1" set="bib1">text</attr>
</map>
</index>
<index search="true" scan="true" sort="false">
<title lang="en">CQL All</title>
<map>
<name set="cql">all</name>
</map>
<map>
<attr type="1" set="bib1">text</attr>
</map>
</index>
<!-- Record ID index -->
<index search="true" scan="true" sort="false">
<title lang="en">Record ID</title>
<map>
<name set="rec">id</name>
</map>
<map>
<attr type="1" set="bib1">rec:id</attr>
<attr type="4" set="bib1">3</attr>
</map>
</index>
खोज¶
इस यूआरएल: http://myserver.com:9999/biblios?version=1.1&operation=searchRetrieve&query=reefs निम्नलिखित तत्वों से बना है:
- एसआरयू सर्वर के आधार यूआरएल: http://myserver.com:9999/biblios?
- 3 आवश्यक पैरामीटर के साथ खोज भाग: संस्करण, संचालन और क्वेरी। खोज भाग के पैरामीटर कुंजी=मान फ़ॉर्म का होना चाहिए, और इसे और चरित्र के साथ जोड़ा जा सकता है।
कोई क्वेरी में वैकल्पिक पैरामीटर जोड़ सकता है, उदाहरण के लिए अधिकतम रिकॉर्ड्स सर्वर द्वारा लौटाए जाने वाले रिकॉर्ड्स की अधिकतम संख्या दर्शाता है। तो http://myserver.com:9999/biblios?version=1.1&operation=searchRetrieve&query=reefs&maximumRecords=5 केवल सर्वर से पहले 5 परिणाम परिणाम प्राप्त करेंगे।
http://www.loc.gov/standards/sru/sru1-1archive/search-retrieve-operation.html खोज संचालन और विशेष रूप से खोज के लिए वैकल्पिक पैरामीटर की सूची के बारे में अधिक जानकारी देता है.
इस "operation"कुंजी के दो मान ले सकते हैं: स्कैन या खोजरिटराइव
यदि operation=searchRetrieve, तो खोज कुंजी क्वेरी होना चाहिए। जैसे की :operation=searchRetrieve&query=reefs
If operation=scan, तो खोज कुंजी स्कैनक्लोज होना चाहिए। जैसे की :operation=scan&scanClause=reefs
etc/zebradb/biblios/etc/bib1.att defines Zebra/3950 अनुक्रमित है कि अपने सिस्टम पर मौजूद परिभाषित करता है। उदाहरण के लिए कि देखेंगे कि हमारे पास इस विषय और शीर्षक के लिए अनुक्रमण है: att 21 विषय और att 4 शीर्षक क्रमशः।
etc/zebradb/pqf.properties के अंतर्गत स्थित pqf.properties फ़ाइल में मैं देखता हूं कि एक एक्सेस पॉइंट पहले से ही मेरे विषय सूचकांक ((index.dc.subject = 1=21) का उपयोग करता है जबकि दूसरा मेरा शीर्षक अनुक्रमणिका (index.dc.title = 1=4) मुझे पता है कि यह मेरा विषय सूचकांक है क्योंकि जैसा कि मैंने अपनी bib1.att फ़ाइल में पहले देखा है, इसे Z3950 में = 1 = 21 के साथ बुलाया गया है: इसलिए index.dc.subject = 1 = 21 सही ढंग से मेरे लिए इंगित करता है विषय सूचकांक और शीर्षक को 1 = 4 के साथ बुलाया गया था इसलिए index.dc.title = 1=4 मेरे शीर्षक सूचकांक को सही ढंग से इंगित करता है। अब मैं अपनी क्वेरी का निर्माण कर सकता हूं जैसे कि मैं एक खोज बॉक्स में, बस "क्वेरी" कुंजी से पहले: query=Subject=reefs और Title=coral खोज में "रीफ्स" और शीर्षक में "कोरल" खोजता हूं। पूरा यूआरएल http://myserver.com:9999/biblios?version=1.1&operation=searchRetrieve&query=Subject=reefs और Title=coral यदि मैं परिणाम सेट को केवल 5 रिकॉर्ड तक सीमित करना चाहता हूं, तो मैं कर सकता हूं http://myserver.com:9999/biblios?version=1.1&operation=searchRetrieve&query=Subject=reefs and Title=coral&maximumRecords=5
मैं भी ट्रंकेट, संबंधों, आदि वे भी मेरे pqf.properties फाइल में परिभाषित कर रहे हैं के साथ खेल सकते हैं। मैं उदाहरण के लिए स्थिति संपत्तियों के रूप में परिभाषित देख सकते हैं:
position.first = 3=1 6=1
# "first in field"
position.any = 3=3 6=1
# "any position in field"
तो उदाहरण के तौर पर यदि मैं शीर्षक की शुरुआत में "कोरल" होना चाहता हूं, तो मैं यह प्रश्न कर सकता हूं:http://myserver.com:9999/biblios?version=1.1&operation=searchRetrieve&query=Title=coral first
वापस निकालना¶
मेरी खोज के लिए http://univ_lyon3.biblibre.com:9999/biblios?version=1.1&operation=searchRetrieve&query=coral reefs&maximumRecords=1 सिर्फ रिकॉर्ड पर पुनर्प्राप्त करता है। प्रतिक्रिया इस तरह दिखती है:
<zs:searchRetrieveResponse>
<zs:version>1.1</zs:version>
<zs:numberOfRecords>1</zs:numberOfRecords>
<zs:records>
<zs:record>
<zs:recordPacking>xml</zs:recordPacking>
<zs:recordData>
<record xsi:schemaLocation="http://www.loc.gov/MARC21/slim http://www.loc.gov/ standards/marcxml/schema/MARC21slim.xsd">
<leader> cam a22 4500</leader>
<datafield tag="010" ind1=" " ind2=" ">
<subfield code="a">2-603-01193-6</subfield>
<subfield code="b">rel.</subfield>
<subfield code="d">159 F</subfield>
</datafield>
<datafield tag="020" ind1=" " ind2=" ">
<subfield code="a">FR</subfield>
<subfield code="b">00065351</subfield>
</datafield>
<datafield tag="101" ind1="1" ind2=" ">
<subfield code="c">ita</subfield>
</datafield>
<datafield tag="105" ind1=" " ind2=" ">
<subfield code="a">a z 00|y|</subfield>
</datafield>
<datafield tag="106" ind1=" " ind2=" ">
<subfield code="a">r</subfield>
</datafield>
<datafield tag="100" ind1=" " ind2=" ">
<subfield code="a">20091130 frey50 </subfield>
</datafield>
<datafield tag="200" ind1="1" ind2=" ">
<subfield code="a">Guide des récifs coralliens / A Guide to Coral Reefs</subfield>
<subfield code="b">Texte imprimé</subfield>
<subfield code="e">la faune sous-marine des coraux</subfield>
<subfield code="f">A. et A. Ferrari</subfield>
</datafield>
<datafield tag="210" ind1=" " ind2=" ">
<subfield code="a">Lausanne</subfield>
<subfield code="a">Paris</subfield>
<subfield code="c">Delachaux et Niestlé</subfield>
<subfield code="d">cop. 2000</subfield>
<subfield code="e">impr. en Espagne</subfield>
</datafield>
<datafield tag="215" ind1=" " ind2=" ">
<subfield code="a">287 p.</subfield>
<subfield code="c">ill. en coul., couv. ill. en coul.</subfield>
<subfield code="d">20 cm</subfield>
</datafield>
......
<idzebra>
<size>4725</size>
<localnumber>2</localnumber>
<filename>/tmp/nw10BJv9Pk/upd_biblio/exported_records</filename>
</idzebra>
</record>
</zs:recordData>
<zs:recordPosition>1</zs:recordPosition>
</zs:record>
</zs:records>
</zs:searchRetrieveResponse>
ILS-DI¶
As of writing, the self documenting ILS-DI is the most complete interface and after it has been enabled as described in the ILS-DI system preferences section the documentation should be available at https://YOURKOHACATALOG/cgi-bin/koha/ilsdi.pl
JSON reports services¶
Koha implements a JSON reports service for every report saved using the Guided Reports Wizard or Report from SQL features.
By default reports will be non-public and only accessible by authenticated users. If a report is explicitly set to public it will be accessible without authentication by anyone. This feature should only be used when the data can be shared safely not containing any patron information.
The reports can be accessed using the following URLs:
- Public reports
- OpacBaseURL/cgi-bin/koha/svc/report?id=REPORTID
- Non-public reports
- StaffBaseURL/cgi-bin/koha/svc/report?id=REPORTID
There are also some additional parameters available:
- Instead of accessing the report by REPORTID you can also use the
report's name:
- .../cgi-bin/koha/svc/report?name=REPORTNAME
- For easier development there is also an option to generate an
annotated output of the data. It will generate an array of hashes
that include the field names as keys.
- .../cgi-bin/koha/svc/report?name=REPORTNAME&annotated=1
Versioned RESTful API Effort¶
There is an ongoing effort to converge the APIs above into a single versioned set of modern RESTful endpoints documented using the OpenAPI standard and available by default under https://YOURKOHACATALOG/api/v1/
OAuth2 client credentials grant¶
Koha supports the OAuth2 client credentials grant as a means to secure the API for using it from other systems to adhere to current industry standards. More information on the OAuth2 client credentials grant standard can be found here.
API key management interface for patrons¶
In order for API keys to be create for patrons, the system preference RESTOAuth2ClientCredentials must be enabled for the option to appear in a patron record.
- Navigate to a patron record and select More > Manage API keys
- If no API keys exist for a patron there will be a message prompting to generate a client id/secret pair
- Enter a description for the client id/secret pair and click Save
Koha will generate a client id/secret pair for use to connect to Koha from other third-party systems as an authenticated client
Clicking the Revoke button next to an API credential pair will render the specific credential pair inactive until reactivated