First of all, I am considering to support https scheme in REST api. However, implementing REST API task was pretty much bigger than expected, so I decided to separate these two HTTP and HTTPS scheme support. HTTPS support will be uploaded in near future, when TAJO-1338 task is finished. Later one looks like implementing authentication on REST API, doesn't it? I also considering about HTTP basic auth using HTTPS and token based authentication. I did not decide yet, and selecting authentication method would be affected by future implementation in security module.
2015-03-20 13:37 GMT+09:00 Dongjoon Hyun <[email protected]>: > Great! I have two questions. (I'm sure you think about these already.) > > 1. What about supporting https together? > 2. What about supporting optional password in Request Message for > supporting future-proof? > { > "userName": "tajo-user", > "userPassword": "password", > "databaseName": "default" > } > > Warmly, > Dongjoon. > > > On Fri, Mar 20, 2015 at 1:25 PM, Jihun Kang <[email protected]> wrote: > > > Hello All, > > > > TAJO REST API design page was created in TAJO wiki page. Please feel free > > to give any comments on this design. You can find details in following > > link. > > > > https://cwiki.apache.org/confluence/display/TAJO/TAJO+REST+API > > > > 2015-03-17 15:13 GMT+09:00 Hyunsik Choi <[email protected]>: > > > > > 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 > > > >> >> >>> > > > > > > > >> >> >>> > > > > > > >> >> >>> > > > > > >> >> >>> > > > > >> >> >>> > > > >> >> > > > >> > > > > > >
