John Blum created GEODE-4787:

             Summary: Re-instate Management REST API endpoints for 'create 
index' and 'created region'.
                 Key: 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 
{{}}, which in Apache Geode 
1.2.1 and earlier, consisted of the following [Spring Web MVC 

However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache Geode 
community refactored and [reduced the 
 and by extension, the Web service endpoints to, mostly, a [single Web service 
 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|], 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

Reply via email to