geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Blum (JIRA)" <>
Subject [jira] [Updated] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
Date Tue, 06 Mar 2018 19:44:00 GMT


John Blum updated GEODE-4787:

> Re-instate Management REST API endpoints for 'create index' and 'create region'
> -------------------------------------------------------------------------------
>                 Key: GEODE-4787
>                 URL:
>             Project: Geode
>          Issue Type: Bug
>          Components: management
>            Reporter: John Blum
>            Priority: Blocker
>         Attachments:,,
> 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 {{}},
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
> 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
> 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

View raw message