hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Lucene-hadoop Wiki] Update of "Hbase/HbaseRest" by BryanDuxbury
Date Thu, 15 Nov 2007 20:09:10 GMT
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 BryanDuxbury:
http://wiki.apache.org/lucene-hadoop/Hbase/HbaseRest

------------------------------------------------------------------------------
  
  ~-''St.Ack comment 11/15/2007: Can you explain 'one less resource'?  (I'm dumb, remember).
 Maybe DELETE ain't that bad.  We might also try and solicit other opinions on this point.
-~ 
  
- ~- 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. -~
+ ~- 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). -~
  
  
  '''DELETE /[table_name]/scanner/[scanner_id]'''
@@ -193, +193 @@

  == Exception Handling ==
  Generally, exceptions will show on the REST client side as 40Xs with a descriptive message
and possibly a body with the java stack trace.  TODO: Table of the types of exceptions a client
could get and how they should react.
  
+ ~- Bryan comment: I think we should only show Java stack traces if we're in some manner
of debug mode. Usually, some REST-based client won't want to know about what's going on under
the hood - they just care that it was a 500 error. We can stick exceptions into the log. -~
+ 

Mime
View raw message