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

["Anthony Baker (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anthony Baker closed GEODE-4787.
--------------------------------

> Re-instate Management REST API endpoints for 'create index' and 'create region'
> -------------------------------------------------------------------------------
>
>                 Key: GEODE-4787
>                 URL: https://issues.apache.org/jira/browse/GEODE-4787
>             Project: Geode
>          Issue Type: Bug
>          Components: management
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: John Blum
>            Priority: Blocker
>              Labels: pull-request-available
>             Fix For: 1.5.0
>
>         Attachments: ClusterConfigurationExampleIntegrationTests.java, Customer.java, CustomerRepository.java
>
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> 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)