Hi CharSyam, Thank you for suggestion. Yes, the REST api will be updated. Please see the attach file at https://issues.apache.org/jira/browse/TAJO-1331. Jihun already wrote the first draft of REST API.
Best regards, Hyunsik On Mon, Mar 16, 2015 at 10:59 PM, CharSyam <[email protected]> wrote: > Yes :) But I think we need good docs for REST api also for client > developers. > > 2015-03-17 14:32 GMT+09:00 Hyunsik Choi <[email protected]>: > >> According to the vote results, let's focus on REST for remote API. >> >> Best regards, >> Hyunsik >> >> On Thu, Mar 12, 2015 at 11:36 PM, Jaehwa Jung <[email protected]> wrote: >> > This discussion started to avoid duplicated efforts. >> > IMPOV, if we choice both of REST and Thrift, it may be complex to >> maintain >> > Tajo codes. >> > >> > 2015-03-13 15:28 GMT+09:00 정유선(JUNG YOUSUN) <[email protected]>: >> > >> >> Yep! I just think both can support multiple language client. >> >> As you mentioned, it is not critical issues about performance in Thrift. >> >> Anyway, I think it's a good discussion about the remote interface on >> Tajo. >> >> :) >> >> >> >> Sincerely, >> >> Yousun Jeong >> >> >> >> -----Original Message----- >> >> From: Hyunsik Choi [mailto:[email protected]] >> >> Sent: Friday, March 13, 2015 2:59 PM >> >> To: [email protected] >> >> Subject: Re: [DISCUSSION] Portable remote client APIs >> >> >> >> Hi Jerry, >> >> >> >> How much faster and lightweight than REST? Luckily, Thrift may be faster >> >> 1~2 msec than REST per call. >> >> >> >> But, note that Tajo is an analytical system. The target response times >> of >> >> Tajo are usually from few seconds to hours. So, the speed which come >> from >> >> wired protocol is much trivial to the purpose of our client APIs. >> >> >> >> The link you introduce is about Hbase. As you know, Hbase is OLTP-like >> >> system. It processes thousands of transactions per seconds. So, the >> speed >> >> and lightweight are important to them. But, Tajo is not. >> >> >> >> As I mentioned, REST API is very portable and has no dependencies in >> many >> >> languages. I think that these are the most important factors of our >> client >> >> APIs. >> >> >> >> Best regards, >> >> Hyunsik >> >> >> >> On Thu, Mar 12, 2015 at 9:33 PM, 정유선 <[email protected]> wrote: >> >> > I suggest another option. >> >> > What do you think about two options for remote interface? >> >> > Thrift is the faster and more lightweight than REST. >> >> > Please refer this article. >> >> > - >> >> > >> http://blog.cloudera.com/blog/2013/03/how-to-use-the-apache-hbase-rest >> >> > -interface-part-1/ It describes various ways to access and interact >> >> > with HBase. >> >> > Both of them, giving developers a wide choice of languages and >> programs >> >> to use. >> >> > >> >> > Best regards, >> >> > Yousun Jeong. >> >> > >> >> > -----Original Message----- >> >> > From: Hyunsik Choi [mailto:[email protected]] >> >> > Sent: Friday, March 13, 2015 8:34 AM >> >> > To: [email protected] >> >> > Subject: Re: [DISCUSSION] Portable remote client APIs >> >> > >> >> > We seem to get a consent to use REST API. I'll wait for one more day, >> >> and then we can decide this issue. >> >> > >> >> > Best regards, >> >> > Hyunsik >> >> > >> >> > On Thu, Mar 12, 2015 at 7:56 AM, Hyoungjun Kim <[email protected]> >> >> wrote: >> >> >> Hi all, >> >> >> >> >> >> I give +1 to REST API. >> >> >> I think REST is more common. >> >> >> >> >> >> Warm regards, >> >> >> Hyoungjun >> >> >> 2015. 3. 12. 오후 10:41에 "Jihun Kang" <[email protected]>님이 작성: >> >> >> >> >> >>> Hello All, >> >> >>> >> >> >>> I would give +1 to REST API Implementation. Even Protobuf and Thrift >> >> >>> give flexibility and extensibility to programmers, but entry >> >> >>> barriers for these frameworks are extremely high. Also, if we want >> >> >>> to make another client implementation for other programming >> >> >>> languages, we need to figure out that these framework have code >> >> generator feature for that programming language. >> >> >>> >> >> >>> 2015-03-12 20:18 GMT+09:00 Jaehwa Jung <[email protected]>: >> >> >>> >> >> >>> > Hi guys >> >> >>> > >> >> >>> > +1 for Hyunsik's suggestion. >> >> >>> > >> >> >>> > REST API may be more efficient for code maintenance and various >> >> >>> > clients implementation. >> >> >>> > >> >> >>> > Cheers >> >> >>> > Jaehwa >> >> >>> > +1 RESTful API for code maintenance >> >> >>> > >> >> >>> > -Jinho >> >> >>> > Best regards >> >> >>> > >> >> >>> > 2015-03-12 17:56 GMT+09:00 CharSyam <[email protected]>: >> >> >>> > >> >> >>> > > +1 >> >> >>> > > >> >> >>> > > I also agree with hyunsik's suggesttion. >> >> >>> > > I think it is better to make language binding to use Rest API. >> >> >>> > > It will be more efficient and less effort :) >> >> >>> > > >> >> >>> > > 2015-03-12 17:38 GMT+09:00 Jihoon Son <[email protected]>: >> >> >>> > > >> >> >>> > > > +1 for Hyunsik's suggestion. >> >> >>> > > > I totally agree with you. >> >> >>> > > > >> >> >>> > > > Warm regards, >> >> >>> > > > Jihoon >> >> >>> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <[email protected]>님이 >> >> 작성: >> >> >>> > > > >> >> >>> > > > > Here is my suggestion. >> >> >>> > > > > >> >> >>> > > > > I prefer REST API. I think that it would be better than >> >> >>> > > > > other due >> >> >>> to >> >> >>> > > > > the following reasons: >> >> >>> > > > > >> >> >>> > > > > * No dependency - most of script languages do not need any >> >> >>> > dependency >> >> >>> > > > > for this approach. Also, C and C++ just needs json library >> >> >>> > > > > for this approach. Please look at JSON for Modern C++ >> >> >>> > > > > (https://github.com/nlohmann/json). It just requires to >> >> >>> > > > > include >> >> >>> one >> >> >>> > > > > header and one source file. As a result, there is no >> >> >>> > > > > dependency problem. >> >> >>> > > > > >> >> >>> > > > > * Portability - most of script languages basically support >> >> >>> > > > > REST >> >> >>> and >> >> >>> > > > > JSON. They don't need client implementation. They can just >> >> >>> > > > > use REST and JSON features in order to access Tajo. If >> >> >>> > > > > necessary, we can >> >> >>> make >> >> >>> > > > > easily some helper libraries for other languages. >> >> >>> > > > > >> >> >>> > > > > * Secure - It is easy to provide the secure channel and >> >> >>> > > > > authentication method too. Basically, many HTTP API provides >> >> >>> > > > > HTTP >> >> >>> > over >> >> >>> > > > > SSL. >> >> >>> > > > > >> >> >>> > > > > Jihoon Kang already started REST API work. If others start >> >> >>> > > > > to >> >> >>> develop >> >> >>> > > > > clients for other languages like C/C++ client over REST API >> >> >>> > > > > after >> >> >>> his >> >> >>> > > > > work, it would be best for us. >> >> >>> > > > > >> >> >>> > > > > Best regards, >> >> >>> > > > > Hyunsik >> >> >>> > > > > >> >> >>> > > > > On Thu, Mar 12, 2015 at 1:32 AM, Hyunsik Choi >> >> >>> > > > > <[email protected]> >> >> >>> > > > wrote: >> >> >>> > > > > > Hi folks, >> >> >>> > > > > > >> >> >>> > > > > > Recently, there are three trials to add new remote client >> >> APIs. >> >> >>> > > > > > >> >> >>> > > > > > * C/C++ Client over Thrift - https://issues.apache.org/ >> >> >>> > > > > jira/browse/TAJO-1264 >> >> >>> > > > > > * Add REST Client API - >> >> >>> > > > https://issues.apache.org/jira/browse/TAJO-1331 >> >> >>> > > > > > * Tajo Python Native Client - https://issues.apache.org/ >> >> >>> > > > > jira/browse/TAJO-1367 >> >> >>> > > > > > >> >> >>> > > > > > In some aspect, I'm very happy to discuss such an issue. I >> >> >>> haven't >> >> >>> > > > > > expected that we are discuss and vote for duplicated >> efforts. >> >> >>> > > > > > >> >> >>> > > > > > BTW, it would be great if we do not spend our resource on >> >> >>> > duplicated >> >> >>> > > > > works. >> >> >>> > > > > > >> >> >>> > > > > > In order to rearrange this duplicated works, we need some >> >> >>> > discussion >> >> >>> > > > > > about their pros and cons. I hope that we consent our >> >> >>> > > > > > direction >> >> >>> > after >> >> >>> > > > > > this discussion. Otherwise, we can call for a vote for the >> >> >>> > approach. >> >> >>> > > > > > >> >> >>> > > > > > Best regards, >> >> >>> > > > > > Hyunsik >> >> >>> > > > > >> >> >>> > > > >> >> >>> > > >> >> >>> > >> >> >>> >> >> >>
