[
https://issues.apache.org/jira/browse/CONNECTORS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888508#action_12888508
]
Karl Wright commented on CONNECTORS-56:
---------------------------------------
Checked in code which I claim constitutes the 0.5 version of the API. This
includes complete json-based operations for the following:
- /job/list
- /job/get
- /job/save
- /job/delete
- /jobstatus/list
- /jobstatus/start
- /jobstatus/abort
- /jobstatus/restart
- /jobstatus/pause
- /jobstatus/resume
- /outputconnection/list
- /outputconnection/get
- /outputconnection/save
- /outputconnection/delete
- /outputconnection/checkstatus
- /repositoryconnection/list
- /repositoryconnection/get
- /repositoryconnection/save
- /repositoryconnection/delete
- /repositoryconnection/checkstatus
- /authorityconnection/list
- /authorityconnection/get
- /authorityconnection/save
- /authorityconnection/delete
- /authorityconnection/checkstatus
Some minor immediate refinements are possible, specifically around the way
error handling is done. Currently, errors that toss exceptions cause a 500
error (with some helpful text). It may be that it's better to get the
exception text back as part of the JSON object being returned.
Comments/preferences welcome.
Also not yet implemented are the following methods:
- /report/documentstatus
- /report/queuestatus
- /report/simplehistory
- /report/maximumbandwidth
- /report/maximumactivity
- /report/resultsummary
These I'd propose to hold of on right now.
I've created a separate ticket for documentation/examples. I'm still intending
to create some tests to exercise at least major portions of the API before
closing THIS ticket.
> All features should be accessible through an API
> ------------------------------------------------
>
> Key: CONNECTORS-56
> URL: https://issues.apache.org/jira/browse/CONNECTORS-56
> Project: Lucene Connector Framework
> Issue Type: Sub-task
> Components: Framework core
> Reporter: Jack Krupansky
>
> LCF consists of a full-featured crawling engine and a full-featured user
> interface to access the features of that engine, but some applications are
> better served with a full API that lets the application control the crawling
> engine, including creation and editing of connections and creation, editing,
> and control of jobs. Put simply, everything that a user can accomplish via
> the LCF UI should be doable through an LCF API. All LCF objects should be
> queryable through the API.
> A primary use case is Solr applications which currently use Aperture for
> crawling, but would prefer the full-featured capabilities of LCF as a
> crawling engine over Aperture.
> I do not wish to over-specify the API in this initial description, but I
> think the LCF API should probably be a traditional REST API., with some of
> the API elements specified via the context path, some parameters via URL
> query parameters, and complex, detailed structures as JSON (or similar.). The
> precise details of the API are beyond the scope of this initial description
> and will be added incrementally once the high-level approach to the API
> becomes reasonably settled.
> A job status and event reporting scheme is also needed in conjunction with
> the LCF API. That requirement has already been captured as CONNECTORS-41.
> The intention for the API is to create, edit, access, and control all of the
> objects managed by LCF. The main focus is on repositories, jobs, and status,
> and less about document-specific crawling information, but there may be some
> benefit to querying crawling status for individual documents as well.
> Nothing in this proposal should in any way limit or constrain the features
> that will be available in the LCF UI. The intent is that LCF should continue
> to have a full-featured UI, but in addition to a full-featured API.
> Note: This issue is part of Phase 2 of the CONNECTORS-50 umbrella issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
