Dear Wiki user, You have subscribed to a wiki page or wiki category on "Lucene-hadoop Wiki" for change notification.
The following page has been changed by stack: http://wiki.apache.org/lucene-hadoop/Hbase/HbaseRest ------------------------------------------------------------------------------ Multipart/related: The client is expecting raw binary data, but organized into a multipart response. The client must be prepared to parse the column values out of the data. + - Options: + Options: + columns: A semicolon-delimited list of column names. If omitted, the result will contain all columns in the row. ~-''St.Ack comment 11/17/2007: Only one column allowed in hbase currently.-~ @@ -96, +98 @@ Headers: Content-type: application/xml: The client is sending one or more columns of data in an XML entity. + Multipart/related: The client is sending multiple columns of data encoded with boundaries. Options: + columns: A semicolon-delimited list of column names. This attribute is ignored when the Content-type is application/xml. Returns: @@ -111, +115 @@ ~-''Bryan comment: While we certainly could use headers, I'd prefer not to. Headers seem like an ugly way to say what you're sending. In REST, you're supposed to specify '''what''' you're acting on in the URI, not headers, and which columns to save to qualifies to me. It may turn out to be an implementation question, but we'll see. ''-~ - ~-''St.Ack comment 11/15/2007: I agree -~ + ~-''St.Ack comment 11/15/2007: I agree -~ + + ~-''St.Ack comment 11/18/2007: If the get on a row is full -- i.e. return all cells in a row -- there is no way for response to say what the column name for the cell is when doing MIME other than put it in the header (Content-Description header?). To be symmetric, maybe client posting data should put column name in same place? I could do implementation so it works with both.-~ '''DELETE /[table_name]/row/[row_key]/''' @@ -121, +127 @@ Delete the specified columns from the row. If there are no columns specified, then it will delete ALL columns. Optionally, specify a timestamp. Options: + columns: A semicolon-delimited list of column names. If omitted, the result will delete all columns in the row. Returns: @@ -131, +138 @@ '''POST/PUT /[table_name]/scanner''' Request that a scanner be created with the specified options. Returns a scanner ID that can be used to iterate over the results of the scanner. + Options: + columns: A semicolon-delimited list of column names. If omitted, each result will contain all columns in the row. start_key, end_key: Starting and ending keys that enclose the region that should be scanned. + + timestamp: Timestamp at which to start the scanner. + Returns: HTTP 201 (Created) with a Location header that references the scanner URI. Example: /first_table/scanner/1234348890231890 + + ~-''St.Ack comment 11/18/2007: I added timestamp parameter. Should start_key, end_key, OR timestamp be on the URL path to sync. with how they are specified GET'ing, etc?-~ + '''GET /[table_name]/scanner/[scanner_id]/current''' Get the row and columns for the current item in the scanner without advancing the scanner. @@ -183, +198 @@ ~- Bryan comment: What I mean is that instead of supporting two separate verbs to two different URIs (/current and /next) there would be only one URI with two verbs. Additionally, after some more thought, I think DELETE would be better because it implies that something is being consumed or deleted, as opposed to POST/PUT which sort of imply something new is being created. Again, though, I think it is a bit of hair splitting, seeing as how the HTTP spec is going to have to be bent a little to work right for this particular request anyways (DELETE or POST/PUT shouldn't usually return an entity-body, and we will want it to so that we don't have to make two separate requests, one for getting the current and another for advancing it). -~ - ~-''St.Ack comment 11/18/2007: Trying to implement, the 'current' tail on a resource URI doesn't add any value GET'ing; what else but the 'current' record would you be GETing. A GET on a URI that ends in a scannerid is enough to figure whats wanted. If this is allowed, given that below a delete on a URI that ends in a scannerid closes the scanner, I would suggest that a PUT/POST on an URI that ends in a scannerid is the way to advance it (returning current value).-~ + ~-''St.Ack comment 11/18/2007: Trying to implement, the 'current' tail on a resource URI doesn't add any value GET'ing; what else but the 'current' record would you be GETing. A GET on a URI that ends in a scannerid is enough to figure whats wanted. If this is allowed, given that below a delete on a URI that ends in a scannerid closes the scanner, I would suggest that a PUT/POST on an URI that ends in a scannerid is the way to advance it (returns the 'next' value -- you have to call 'next' on scanner to get first value).-~ '''DELETE /[table_name]/scanner/[scanner_id]'''
