[ 
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16388363#comment-16388363
 ] 

John Blum edited comment on GEODE-4787 at 3/6/18 7:22 PM:
----------------------------------------------------------

This *bug(!)* exists because it broke _Spring Data for Apache Geode's_ [Cluster 
Configuration 
Push|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-cluster]
 feature, which as we know is used by a Pivotal GemFire user when creating 
_Spring Boot_ with _Spring Data GemFire_, and by extension, Pivotal GemFire, 
{{ClientCache}} applications in a PCF context using PCC.

The 
[implementation|https://github.com/spring-projects/spring-data-geode/blob/2.0.5.RELEASE/src/main/java/org/springframework/data/gemfire/config/admin/remote/RestHttpGemfireAdminTemplate.java]
 of _Cluster Configuration Push_ was well communicated (and I thought known) 
since it was discussed many times at the PCC working group meeting.



was (Author: jblum):
This *bug(!)* exists because it broke _Spring Data for Apache Geode's_ [Cluster 
Configuration 
Push|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-cluster]
 feature, which as we know is used by Pivotal GemFire user when creating 
_Spring Boot_ with _Spring Data GemFire_, and by extension, Pivotal GemFire, 
{{ClientCache}} applications in a PCF when using PCC.

The 
[implementation|https://github.com/spring-projects/spring-data-geode/blob/2.0.5.RELEASE/src/main/java/org/springframework/data/gemfire/config/admin/remote/RestHttpGemfireAdminTemplate.java]
 of _Cluster Configuration Push_ was well communicated (and I thought known) 
since it was discussed many times at the PCC working group meeting.


> 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
>            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
(v7.6.3#76005)

Reply via email to