incubator-connectors-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Krupansky (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CONNECTORS-56) All features should be accessible through an API
Date Fri, 16 Jul 2010 17:32:51 GMT

    [ https://issues.apache.org/jira/browse/CONNECTORS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889237#action_12889237
] 

Jack Krupansky commented on CONNECTORS-56:
------------------------------------------

It has come to my attention that the API would be more "pure" RESTful if the API verb was
represented using the HTTP GET/PUT/DELETE verb and the input argument identifier represented
in the context path.

So,  GET outputconnection/get \{"connection_name":_<connection_name>_\} would be GET
outputconnections/<connection_name>

and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE
outputconnections/<connection_name>

and GET outputconnection/list would be GET outputconnections

and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would
be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}

What we have today is certainly workable, but just not as "pure" as some might desire.

I am not going to classify this as a required issue just yet, but this would be a great time
to change things before the API gets cast in concrete.

Comments?


> 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
>            Assignee: Karl Wright
>
> 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.


Mime
View raw message