Re: Operator HTTP endpoints

+1 on *Request -> *Info :). Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer Platform OpenSource Technology, STG, IBM GCG +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me On Mon, Jan 18, 2016 at 7:38 PM, Alex Rukletsov wrote: > I agree that the

Re: Operator HTTP endpoints

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

Re: Operator HTTP endpoints

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

Re: Operator HTTP endpoints

+1 for adding "force" in JSON body; used to be a JEE developer for several years, there's a general practice to us: query argument (e.g. "?force=true") is ONLY used by 'GET', all "data" are in body if action is 'POST' (e.g. UPDATE, DELETE). The reason is complex: security, meaning of HTTP action,

Re: Operator HTTP endpoints

+1 for Lukas's suggestion to have `force` be a query argument (eg, ``?force=true``) and the body respect the ``Content-Type`` header. (although I was part of the conversation of adding the ``force`` flag to the SUBSCRIBE message, I forget the exact details of that one - @Vinod may be able to