hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Nichols" <tmnich...@gmail.com>
Subject Re: [jira] Commented: (HBASE-1064) HBase REST xml/json improvements
Date Wed, 17 Dec 2008 16:37:50 GMT
Why not keep the old format of :
 /[table_name]/row/[row_key]/[timestamp]
for direct row access?

The benefit ("more restful in spirit") doesn't seem to gain a lot in
practice.  Plus if you think of a scanner as a resource, then it
should be part of a URL, not an "action."  Your propsed change means
doing PUT/POST/DELETE options on  /[table_name]/scanner/[scanner_id]
no longer work.

So while a /tablename/[row]/[column]/[timestamp] format may be more
RESTful for direct, single-row access, it assumes a table only has
rows, not stateful scanner instances as well.  I would argue scanners
should continue to be treated as a resource, not an action.

Maybe if you made scanners a "root-level" type, i.e. POST
/scanner/[params] and GET /scanner/id ... Maybe that would work.

"Enable" and "Disable" make sense as actions on a (table) resource
possibly as well, so they fit with your model.  But "regions" sounds
like a resource again...  Maybe not.

Anyway, that's my gut reaction.  I'd just strongly consider what
benefit would be gained by the proposed interface versus the existing
one.  Maybe it would be helpful to think of what other "resources" and
"actions" could possibly be added to the REST interface in the long
term.  MapReduce jobs?  Pig jobs?  etc etc.  Would they be root-level
resources, properties of a table resource, or actions on a table?

-Tom


On Wed, Dec 17, 2008 at 11:07 AM, Brian Beggs (JIRA) <jira@apache.org> wrote:
>
>    [ 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.
>
>

Mime
View raw message