My initial thoughts on this was to take the current REST implementation
that returns xml and refactor it so other types of content could be
returned. Separating out the content generation and parsing from the
servlet code.
I do think that it would be beneficial to allow multiple types of
content to be returned by the implementation. I also believe that
adding a new content type should be fairly simple to add. I'm not a fan
of having dual REST implementations as provided by the patch in these
JIRA issues:
https://issues.apache.org/jira/browse/HBASE-814
https://issues.apache.org/jira/browse/HBASE-815
What I think I'm going to do at this point is to refactor the current
REST implementation to allow multiple enocoders and parsers to work with
the servlets.
Brian
-----Original Message-----
From: Michael Stack [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 7:08 PM
To: [email protected]
Cc: [EMAIL PROTECTED]
Subject: Re: JSON support for HBaseRest
Tom and Andrew, you are right. Response should be based off the
requested content-type (Actually, this is the way it was orginally
written but only XML was every implemented: See
http://tinyurl.com/5podrd).
St.Ack*
*
Tom Nichols wrote:
> I agree that you wouldn't want to replace one completely with the
> other, but allow for multiple content encodings. We're also
> interested in CSV (at least as a retrieval format). The current REST
> classes would need to be refactored in order to separate the content
> parsing & generation from the actual request and response handling. A
> simple switch statement based on the content-type (for request) and
> accept header (for response) should be enough; a delegating chain of
> command type of pattern could be slightly more flexible in terms of
> adding new content encodings, but it would probably be overkill.
>
> On Wed, Nov 19, 2008 at 5:50 PM, Andrew Purtell <[EMAIL PROTECTED]>
wrote:
>
>>> From: stack <[EMAIL PROTECTED]>
>>> I'd be on for replacing our current XML-based with JSON
>>> if others were OK with that.
>>>
>> I agree that JSON is preferable to XML as the default response
>> encoding, but XML should be supported IMHO. In some environments
>> XML is heavily favored, rightly or wrongly.
>>
>> - Andy
>>
>>
>>> From: stack <[EMAIL PROTECTED]>
>>> Subject: Re: JSON support for HBaseRest
>>> To: [email protected]
>>> Date: Wednesday, November 19, 2008, 1:06 PM
>>> Sishen Freecity has been looking after our REST interface of
>>> late. He'd be the best person to chat with. From my
>>> POV, for sure we'd be interested. Someone had begun
>>> work on this a while back but it may have been dropped.
>>> I'd be on for replacing our current XML-based with JSON
>>> if others were OK with that.
>>>
>>> Thanks Brian,
>>> St.Ack
>>>
>>> Brian Beggs wrote:
>>>
>>>> I am currently working on adding JSON support to the
>>>>
>>> HBase Rest
>>>
>>>> implementation. I wanted to contact the HBase
>>>>
>>> developer community to
>>>
>>>> see if either something like this was already being
>>>>
>>> worked on and if
>>>
>>>> this something that the community would be interested
>>>>
>>> in having.
>>>
>>>> Thanks,
>>>>
>>>>
>>>> Brian
>>>>
>>>>
>>>> This email and any information disclosed in connection
>>>>
>>> herewith, whether written or oral, is the property of
>>> EnerNOC, Inc. and is intended only for the person or entity
>>> to which it is addressed. This email may contain
>>> information that is privileged, confidential or otherwise
>>> protected from disclosure. Distributing or copying any
>>> information contained in this email to anyone other than the
>>> intended recipient is strictly prohibited.
>>>
>>>>
>>
>>
>>
This email and any information disclosed in connection herewith, whether
written or oral, is the property of EnerNOC, Inc. and is intended only for the
person or entity to which it is addressed.
This email may contain information that is privileged, confidential or
otherwise protected from disclosure.
Distributing or copying any information contained in this email to anyone other
than the intended recipient is strictly prohibited.
