gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lewis John Mcgibbney <lewis.mcgibb...@gmail.com>
Subject Re: Gora REST API
Date Sun, 09 Nov 2014 05:35:09 GMT
Hi Folks,
OK, I've finished a first pass at implementation of all of the CRUD and
Schema operations associated with the DataStore API [0].
The draft REST API spec and documentation can be found here [1].
The functionality I have neglected to implement so far includes the
following list. Please keep reading after this list as there is more
content on my own criticisms of the current API as defined in the

void close()
Close the DataStore.

Result<K,T> execute(Query<K,T> query)
Executes the given query and returns the results.

void flush()
Forces the write caches to be flushed.

BeanFactory<K,T> getBeanFactory()
Returns the BeanFactory used by the DataStore

Class<K> getKeyClass()
Returns the class of the keys

List<PartitionQuery<K,T>> getPartitions(Query<K,T> query)
Partitions the given query and returns a list of PartitionQuerys, which
will execute on local data.

Class<T> getPersistentClass()
Returns the class of the persistent objects

void initialize(Class<K> keyClass, Class<T> persistentClass,
Properties properties)
Initializes this DataStore.

K newKey()
Returns a new instance of the key object.

T newPersistent()
Returns a new instance of the managed persistent object.

Query<K,T> newQuery()
Constructs and returns a new Query.

void setBeanFactory(BeanFactory<K,T> beanFactory)
Sets the BeanFactory to use by the DataStore.

void setKeyClass(Class<K> keyClass)
Sets the class of the keys

void setPersistentClass(Class<T> persistentClass)
Sets the class of the persistent objects

If we wish to implement any of the above then i am happy to do so, but my
understanding is that these are all taken care of programmatically within
the server side code execution. The exceptions to this comment are possibly
close and flush.

I have some concerns here, these have mainly to do with the current design
of the DataStore API and the limitations it poses for us when implementing
a clean and intuitive REST API, namely

   - Once I've created a schema within the DataStore how do I delete one or
   more schema(s) when the method call to void deleteSchema() [2] does not
   permit me to define which schema I wish to delete?
   - The same goes for getting one or more schema(s) information for one
   particular schema(s)
   - The same exists for determining if one or more particular schema(s)
   - The same exists for truncating data which exists under one or more

The above questions are my main pain points right now as I feel that
extending the DataStore API in order to address such requirements is quite
a major step seeing as DataStore is THE main Gora API!
I have recently been tracking a very promising project [6] which is
described as "...a RESTful web service for storing and serving mappings
between schema identifiers and schema definitions." This may help us out
for storing schema information which may be potentially leveraged to reduce
direct impact on the Gora Datastore API but this is still slightly unclear
to me right now.

Anyways, I hope that this is a decent start towards us implementing the
REST API for Gora.

BTW, if anyone wishes to comment on the apiary documentation I can grant
you perms so please send me your details if you wish to be added.

[1] http://docs.apachegoraapi.apiary.io/
[6] https://github.com/schema-repo/schema-repo

On Thu, Nov 6, 2014 at 9:12 AM, Lewis John Mcgibbney <
lewis.mcgibbney@gmail.com> wrote:

> Hi Folks,
> I've started documenting how I think we could implement a REST API in Gora.
> This is in early stages but when i good a good crack at it we can move it
> on quickly.
> The documentation can be found here
> http://docs.apachegoraapi.apiary.io/
> I would REALLY like some help on this if anyone is obliged to do so.
> The aim here is that this will be the GOTO for documentation, we can then
> implement the actual API in Apache CXF [0] (which we already pull to
> satisfy Hadoop dependencies) and implement it via CXF's JAXRS
> implementation[1].
> Lewis
> [0] http://cxf.apache.org
> [1] http://cxf.apache.org/docs/jax-rs.html
> --
> *Lewis*


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message