John Blum created GEODE-4787:
--------------------------------
Summary: Re-instate Management REST API endpoints for 'create
index' and 'created region'.
Key: GEODE-4787
URL: https://issues.apache.org/jira/browse/GEODE-4787
Project: Geode
Issue Type: Bug
Components: gfsh, management
Reporter: John Blum
As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper (REST-like)
Web service endpoints for the Geode's Management functionality.
This primarily concerns the Management (REST-like) Web service API in
{{org.apache.geode.management.internal.web.controllers}}, which in Apache Geode
1.2.1 and earlier, consisted of the following [Spring Web MVC
Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache Geode
community refactored and [reduced the
Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
and by extension, the Web service endpoints to, mostly, a [single Web service
endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
which essentially just accepts a _Gfsh_ command string, such as `{{create
region --name=Example --type=PARTITION}}`.
This is an significant *anti-pattern* to be sure nor is it consistent with
good/proper Web service/general API design, much less REST-ful design.
While this Management REST-like API was not a "complete" REST API design, as
measured against [Richardson Maturity
Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
consist of elements in both Levels 1 and 2.
For instance, it used proper URLs and URIs to identify and access resources
(e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
affect (e.g. CRUD) the resources.
Essentially, it only needed proper Resource abstractions representing the
different resources (e.g. Regions, Indexes, etc) along with Hypermedia Controls
to move beyond being a specific interface for _Gfsh_.
The intent was never to make the Management REST API a specific extension for
_Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager via
HTTP in order to transcend firewalls when a devops team wanted to manage a
remote cluster deployed in a cloud environment, such as AWS or GCP. By using
HTTP over JMX/RMI, a user would not need to punch additional holes in the
firewall to expose the JMX/RMI port (1099) for instance.
Still, the "intent" was never to stop at supporting just _Gfsh_, but to become
a true REST API that can be consumed by any client (not just _Gfsh_):
application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
Ruby, Python, etc).
However, the team that modified this API failed to recognize the benefit of
this design and actually took a step backwards. The HTTP Verbs are not
properly used. The Web service API endpoints are not resourceful, and imposing
the _Gfsh_ DSL on clients is foolish and too restrictive.
While, it might be argued that this was an "internal" API, technically,
speaking, guarding classes by putting them in an "internal" package is no
safe-guard or guarantee that could have been properly enforced using Java
access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
exposing an SPI for consumption.
The fact remains that this API was changed in an incompatible way before an
"alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
