I agree that the borderline between being related to the request and being
related to the way the request is processed is vague. I think having
*Request objects is a good idea, both for documenting the JSON request
schema and differentiating between the request and storage data.
However, I'm a bit reluctant to nest QuotaInfo in QuotaRequest. Since
QuotaInfo is what we persist in the master (and the registry), it may have
fields that are not relevant to the request (e.g., "principal"), hence we
should validate these fields are not set and document that. I would suggest
to untie *Request and *Info protos and perform conversions *Request ->
*Info.
On Fri, Jan 15, 2016 at 10:09 PM, Benjamin Mahler <bmah...@apache.org>
wrote:
> The distinction between being related to the request vs. how the request
> should be processed seems arguable, do you feel that we'll be able to make
> the distinction easily?
>
> One thought.. if there are top-level Request objects:
>
> message QuotaRequest {
> optional bool force;
> required QuotaInfo quota_info;
> }
>
> Then we could map query parameters to fields, so the following are
> equivalent:
>
> /quota?force=true
> {
> "quota_info": { ...}
> }
>
> /quota
> {
> "force": true,
> "quota_info": { ...}
> }
>
> The user can choose between query parameters vs json body as they please,
> and we still have a single specification of the request.
>
> On Thu, Jan 14, 2016 at 10:09 AM, Alex Rukletsov <a...@mesosphere.com>
> wrote:
>
> > Folks,
> >
> > I would like to gather your opinions about a concern related to operator
> > HTTP endpoints. From one side we agreed that for simplicity and
> consistency
> > we should bake all request data in a single JSON. From the other side,
> some
> > parameters, like a force flag, do not really belong to request JSON (as
> > pointed out by some SRE guys in comment to MESOS-3914 [1]). The force
> flag
> > is not really related to the request itself, but more to the way the
> > request should be processed.
> >
> > To my knowledge, currently we use the force flag in two places:
> > * Subscribe call in framework API.
> > * Quota set request.
> >
> > Currently we have the 'force' field in JSON both cases.
> >
> > I would like us to agree on the way we write endpoints and clean-up
> > existing ones *before* we release Mesos 1.0. Looking forward to your
> > feedback.
> >
> > AlexR
> >
> > [1] https://issues.apache.org/jira/browse/MESOS-3914
> >
>
