[
https://issues.apache.org/jira/browse/HBASE-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657437#action_12657437
]
Brian Beggs commented on HBASE-1064:
------------------------------------
I'm not sure if Michael Gottesman reads the dev list or not but he may want to
comment on what I'm about to say.
First let me point out the differences.
current REST implementation:
the path that follows the url is in this format /tablename/<action>/[additional
info]
where action can be enable/disable a table, a scanner or a call to retrieve a
row.
In the implementation I'm working on the path that follows the url is in this
format:
/tablename/[row]/[column]/[timestamp]
Also a query string can be included depending on what you wanted to do.
For example to get table regions data with this implementation:
http://localhost:60050/<tableName>?action=regions
the current way:
http://localhost:60050/<tableName>/regions
or to get a scanner with this implemenation:
http://localhost:60050/<tableName>?action=newscanner
the current way:
http://localhost:60050/<table_name>/scanner
As you can see the interface is a bit different where as the implementation I'm
working on is perhaps a bit more restful in spirit.
Also the reason for the change in moving to the query string for some of these
items is that in order to retrieve the row/column/timestamp using the path you
are unable to have any directives in the path. Unless we wanted to get into
the thought of reserved words, which IMHO is a bad idea and complicates the
interface.
Now I think the real question that needs to be answered... is it necessary or
desirable to query out the row/column/timestamp data in this RESTful fashion
using the path?
If no the interface can be changed to be much closer to the current
implementation.
If yes, then the interface needs to change.
To be honest, a change like this is not currently on my roadmap, though I feel
it could be done with a few days worth of work. Obviously I do not desire to
break anyones current interface into the system, but at the same time you can't
make an omelet without breaking a few eggs. And I also fee that if a big change
to something like this does go in, sooner is probably better than later as
adoption of this project picks up.
I also am not sure if I have an opinion either way on the interface. I tend to
like the new model a bit better, but I think that the questions that really
needs to be answered are, what are the needs of the users of the rest interface
currently? Are they getting everything they need? Could the interface be
better? Is there a need for a better interface? Will the current interface
meet the demands of future users? Is the current interface extensible enough
to allow the HBase project to expand in the future?
And I really don't have the answer to these questions. I'm still somewhat of
an hbase noob.
> HBase REST xml/json improvements
> --------------------------------
>
> Key: HBASE-1064
> URL: https://issues.apache.org/jira/browse/HBASE-1064
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: rest
> Reporter: Brian Beggs
> Attachments: json2.jar, RESTPatch-pass1.patch
>
>
> I've begun work on creating a REST based interface for HBase that can use
> both JSON and XML and would be extensible enough to add new formats down the
> road. I'm at a point with this where I would like to submit it for review
> and to get feedback as I continue to work towards new features.
> Attached to this issue you will find the patch for the changes to this point
> along with a necessary jar file for the JSON serialization. Also below you
> will find my notes on how to use what is finished with the interface to this
> point.
> This patch is based off of jira issues:
> HBASE-814 and HBASE-815
> I am interested on gaining feedback on:
> -what you guys think works
> -what doesn't work for the project
> -anything that may need to be added
> -code style
> -anything else...
> Finished components:
> -framework around parsing json/xml input
> -framework around serialzing xml/json output
> -changes to exception handing
> -changes to the response object to better handle the serializing of output
> data
> -table CRUD calls
> -Full table fetching
> -creating/fetching scanners
> TODO:
> -fix up the filtering with scanners
> -row insert/delete operations
> -individual row fetching
> -cell fetching interface
> -scanner use interface
> Here are the wiki(ish) notes for what is done to this point:
> REST Service for HBASE Notes:
> GET /
> -retrieves a list of all the tables with their meta data in HBase
> curl -v -H "Accept: text/xml" -X GET -T - http://localhost:60050/
> curl -v -H "Accept: application/json" -X GET -T - http://localhost:60050/
> POST /
> -Create a table
> curl -H "Content-Type: text/xml" -H "Accept: text/xml" -v -X POST -T -
> http://localhost:60050/newTable
> <table>
> <name>test14</name>
> <columnfamilies>
> <columnfamily>
> <name>subscription</name>
> <max-versions>2</max-versions>
> <compression>NONE</compression>
> <in-memory>false</in-memory>
> <block-cache>true</block-cache>
> </columnfamily>
> </columnfamilies>
> </table>
> Response:
> <status><code>200</code><message>success</message></status>
> JSON:
> curl -H "Content-Type: application/json" -H "Accept: application/json" -v -X
> POST -T - http://localhost:60050/newTable
> {"name":"test5", "column_families":[{
> "name":"columnfam1",
> "bloomfilter":true,
> "time_to_live":10,
> "in_memory":false,
> "max_versions":2,
> "compression":"",
> "max_value_length":50,
> "block_cache_enabled":true
> }
> ]}
> *NOTE* this is an enum defined in class HColumnDescriptor.CompressionType
> GET /[table_name]
> -returns all records for the table
> curl -v -H "Accept: text/xml" -X GET -T - http://localhost:60050/tablename
> curl -v -H "Accept: application/json" -X GET -T -
> http://localhost:60050/tablename
> GET /[table_name]
> -Parameter Action
> metadata - returns the metadata for this table.
> regions - returns the regions for this table
> curl -v -H "Accept: text/xml" -X GET -T -
> http://localhost:60050/pricing1?action=metadata
> Update Table
> PUT /[table_name]
> -updates a table
> curl -v -H "Content-Type: text/xml" -H "Accept: text/xml" -X PUT -T -
> http://localhost:60050/pricing1
> <columnfamilies>
> <columnfamily>
> <name>subscription</name>
> <max-versions>3</max-versions>
> <compression>NONE</compression>
> <in-memory>false</in-memory>
> <block-cache>true</block-cache>
> </columnfamily>
> <columnfamily>
> <name>subscription1</name>
> <max-versions>3</max-versions>
> <compression>NONE</compression>
> <in-memory>false</in-memory>
> <block-cache>true</block-cache>
> </columnfamily>
> </columnfamilies>
> curl -v -H "Content-Type: application/json" -H "Accept: application/json" -X
> PUT -T - http://localhost:60050/pricing1
> {"column_families":[{
> "name":"columnfam1",
> "bloomfilter":true,
> "time_to_live":10,
> "in_memory":false,
> "max_versions":2,
> "compression":"",
> "max_value_length":50,
> "block_cache_enabled":true
> },
> {
> "name":"columnfam2",
> "bloomfilter":true,
> "time_to_live":10,
> "in_memory":false,
> "max_versions":2,
> "compression":"",
> "max_value_length":50,
> "block_cache_enabled":true
> }
> ]}
> Delete Table
> curl -v -H "Content-Type: text/xml" -H "Accept: text/xml" -X DELETE -T -
> http://localhost:60050/TEST16
> creating a scanner
> curl -v -H "Content-Type: application/json" -H "Accept: application/json" -X
> POST -T - http://localhost:60050/TEST16?action=newscanner
> //TODO fix up the scanner filters.
> response:
> xml:
> <scanner>
> <id>
> 2
> </id>
> </scanner>
> json:
> {"id":1}
> Using a scanner
> curl -v -H "Content-Type: application/json" -H "Accept: application/json" -X
> POST -T -
> "http://localhost:60050/TEST16?action=scan&scannerId=<scannerID>&numrows=<num
> rows to return>"
> This would be my first submission to an open source project of this size, so
> please, give it to me rough. =)
> Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
