Details
-
Bug
-
Status: Closed
-
Blocker
-
Resolution: Fixed
-
1.3.0, 1.4.0
Description
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.
However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache Geode community refactored and reduced the Controllers, and by extension, the Web service endpoints to, mostly, a single Web service endpoint, 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.
