[
https://issues.apache.org/jira/browse/CONNECTORS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902940#action_12902940
]
Mark Miller commented on CONNECTORS-56:
---------------------------------------
bq. HTTP methods other than GET or PUT are in fact poorly supported in many
HTTP clients, including Apache Commons HTTPClient.
That's untrue.
bq. I am also unsure of whether Jetty supports the DELETE method at the
servlet level.
Jetty has no issues with DELETE, POST, PUT, or GET. Nor does Tomcat or any
other container I have seen.
bq. I therefore think your suggestion would potentially cause a great deal of
headache for no tangible benefit.
Again, I don't agree - it would cause less headaches, as REST is somewhat of a
standard rather than an ad hoc api. There are many advantages to having a
consistent RESTful api.
> All features should be accessible through an API
> ------------------------------------------------
>
> Key: CONNECTORS-56
> URL: https://issues.apache.org/jira/browse/CONNECTORS-56
> Project: Apache Connectors 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.
