Return-Path: X-Original-To: apmail-asterixdb-dev-archive@minotaur.apache.org Delivered-To: apmail-asterixdb-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5BC8519FCA for ; Fri, 15 Apr 2016 21:48:10 +0000 (UTC) Received: (qmail 57468 invoked by uid 500); 15 Apr 2016 21:48:10 -0000 Delivered-To: apmail-asterixdb-dev-archive@asterixdb.apache.org Received: (qmail 57409 invoked by uid 500); 15 Apr 2016 21:48:10 -0000 Mailing-List: contact dev-help@asterixdb.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@asterixdb.incubator.apache.org Delivered-To: mailing list dev@asterixdb.incubator.apache.org Received: (qmail 57395 invoked by uid 99); 15 Apr 2016 21:48:10 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2016 21:48:10 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 91181C157A for ; Fri, 15 Apr 2016 21:48:09 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -5.016 X-Spam-Level: X-Spam-Status: No, score=-5.016 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id 2PtvE-TNyLl4 for ; Fri, 15 Apr 2016 21:48:09 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with SMTP id 8A70C5FAD3 for ; Fri, 15 Apr 2016 21:48:08 +0000 (UTC) Received: (qmail 57384 invoked by uid 99); 15 Apr 2016 21:48:08 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2016 21:48:08 +0000 Received: from [192.168.1.229] (99-113-32-174.lightspeed.sntcca.sbcglobal.net [99.113.32.174]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 8A1CE1A0488; Fri, 15 Apr 2016 21:48:07 +0000 (UTC) From: "Till Westmann" To: "Wail Alkowaileet" Cc: dev@asterixdb.incubator.apache.org, "Chris Hillery" Subject: Re: New Asterix REST API design Date: Fri, 15 Apr 2016 14:48:06 -0700 Message-ID: <7CCC0E40-4B18-4521-9630-3978D46CF809@apache.org> In-Reply-To: References: <21E0A234-8BED-4DB5-BCFA-C84A3A5C4B34@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Hi Wail, I’m not completely sure that I understand how to implement the idea. If we do this only in the API, it might be tricky to get the boundaries between records right (e.g. if we do indentation on the server). However, if we want to push this into the query engine, we need to understand enough of the query/statements to put the limit clause in. Both approaches don't look great to me. What did you have in mind? Cheers, Till On 15 Apr 2016, at 13:19, Wail Alkowaileet wrote: > Hi Ildar, > I think if there's something I would love to have is getting partial > result > instead of all result at once. This can be beneficial for result > pagination. When I use AsterixDB UI, 50% of the time my tab crashes (I > forget to limit the result). > > Thanks... > > On Fri, Apr 15, 2016 at 1:23 AM, Ildar Absalyamov < > ildar.absalyamov@gmail.com> wrote: > >> Hi Devs, >> >> Recently there have been a number of conversations about the future >> of our >> REST (aka HTTP) API. I summarized these discussions in an outline of >> the >> new API design: >> https://cwiki.apache.org/confluence/display/ASTERIXDB/New+HTTP+API+Design >> >> . >> The need to refactor existing API came from different directions (and >> from >> different people), and is explained in motivation section. Thus I >> believe >> it’s about the time to take an effort and improve existing API, so >> that it >> will not drag us down in the future. However during the transition >> step I >> believe it would be better to keep exiting API endpoints, so that we >> would >> not break people’s current experimental setup. >> >> It would be good to know feedback from the folks, who have been >> contributing to that part of the systems recently. >> >> Best regards, >> Ildar >> >> > > > -- > > *Regards,* > Wail Alkowaileet