[jira] [Created] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'created region'.

["John Blum (JIRA)" <ji...@apache.org>]

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)