[
https://issues.apache.org/jira/browse/TIKA-3082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072998#comment-17072998
]
Lewis John McGibbney commented on TIKA-3082:
--------------------------------------------
[~grossws] absolutely.
# Firstly, OpenAPI is the industry standard for API first implementations
meaning that moving forward the goal would be for our REST to be more user and
developer friendly.
# OpenAPI has a wide variety of tooling meaning that people could generate both
server stub implementations and client implementations on the fly at their own
convenience whilst we (the dev@tika community) maintain the existing
tika-server Java implementation.
# There are several Java server stub generation options for us to use, namely
{code:java}
java-inflector
java-msf4j
java-pkmst
java-play-framework
java-undertow-server
java-vertx
java-vertx-web (beta)
jaxrs-cxf
jaxrs-cxf-cdi
jaxrs-cxf-extended
jaxrs-jersey
jaxrs-resteasy
jaxrs-resteasy-eap
jaxrs-spec
{code}
... I think we would choose *jaxrs-cxf* in an attempt to cause minimal impact
on the existing tika-server code. wdyt?
# I tend to use [IBM's OpenAPI linter and
validator|https://github.com/IBM/openapi-validator] in an attempt to obtain
consistency in the quality of my REST API development. I think that this tool
would make it easier for us to ensure we have adequate documentation coverage
for all parameters, responses, headers, paths, exceptions, etc.
> Consider adding an OpenAPI for tika-server
> ------------------------------------------
>
> Key: TIKA-3082
> URL: https://issues.apache.org/jira/browse/TIKA-3082
> Project: Tika
> Issue Type: Task
> Reporter: Tim Allison
> Priority: Major
>
> On TIKA-2253, [~lewismc] asked:
> bq. I was planning on putting together an OpenAPI specification for Tika. Is
> anyone in favor of this?
> What do people think? How much will it change the current tika-server? What
> are the benefits?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
