John Blum updated GEODE-4787:
    Component/s:     (was: gfsh)

> 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: management
>            Reporter: John Blum
>            Priority: Blocker
> 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

Reply via email to