[
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:26 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. It
naturally followed and used the individual Management REST-like API Web service
endpoints (e.g. {{`POST
http://localhost:8080/gemfire/v1/regions?name=Example&type=PARTITION`}}).
It would be unreasonable to force applications, frameworks and tools to have to
conform _Gfsh_ command syntax/DSL, for reasons that I cited above.
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 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.
> 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)
