----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/49730/#review141097 -----------------------------------------------------------
Looks good overall! Nothing major (just minor typos) + some comments around some details that are not required for a user doc. docs/operator-http-api.md (line 8) <https://reviews.apache.org/r/49730/#comment206497> s/V1/v1 to be consistent with the other docs. docs/operator-http-api.md (line 13) <https://reviews.apache.org/r/49730/#comment206498> Kill the second sentence? It seems odd to have the details about the choice of endpoints (`/api/v1` vs `/api/v1/operator`) in a user doc. docs/operator-http-api.md (lines 15 - 17) <https://reviews.apache.org/r/49730/#comment206500> hmm, we already included the the endpoint details in the last line, no? Why do it again here? We don't do so in the scheduler/executor docs either. docs/operator-http-api.md (line 19) <https://reviews.apache.org/r/49730/#comment206501> 1. s/Following the same pattern as the/Similar to the 2. comma after HTTP APIs 3. s/we limit all all interactions with this API through/the endpoints only accept HTTP POST 4. It's a bit unintuitive that the doc talks about `Calls` directly without explaining what they are? docs/operator-http-api.md (line 21) <https://reviews.apache.org/r/49730/#comment206503> 1. s/that must be present in the request/present in the request. It's not mandatory for the header to be present. Should we also mention that we default to JSON if no accept header is present? 2. s/header **Accept-Encoding**/**Accept-Encoding** header 3. s/200/200 OK docs/operator-http-api.md (line 23) <https://reviews.apache.org/r/49730/#comment206505> s/202/202 Accepted s/gzip compression/Currently, gzip docs/operator-http-api.md (line 25) <https://reviews.apache.org/r/49730/#comment206507> 1. comma after future Also, wondering if we should include this in the user doc? docs/operator-http-api.md (line 29) <https://reviews.apache.org/r/49730/#comment206508> s/technically// s/for those/for them docs/operator-http-api.md (line 33) <https://reviews.apache.org/r/49730/#comment206509> s/technically// s/for those/for them docs/operator-http-api.md (line 34) <https://reviews.apache.org/r/49730/#comment206512> Can we include a Calls section similar to what we do for the scheduler/executor docs? docs/operator-http-api.md (line 107) <https://reviews.apache.org/r/49730/#comment206510> s/!/. docs/operator-http-api.md (line 142) <https://reviews.apache.org/r/49730/#comment206511> It's a bit confusing to see the "possibly compressed" line. Can we remove it since we don't support it currently? docs/operator-http-api.md (line 144) <https://reviews.apache.org/r/49730/#comment206513> Can we put these in a "Events" section? docs/operator-http-api.md (line 148) <https://reviews.apache.org/r/49730/#comment206514> s/See the above/See `SUBSCRIBE` above s/state result/state can result s/other events/more events docs/operator-http-api.md (line 152) <https://reviews.apache.org/r/49730/#comment206515> s/This event is sent/This can happen docs/operator-http-api.md (line 183) <https://reviews.apache.org/r/49730/#comment206516> s/This event is typically sent/This can happen - Anand Mazumdar On July 6, 2016, 10:46 p.m., Vinod Kone wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/49730/ > ----------------------------------------------------------- > > (Updated July 6, 2016, 10:46 p.m.) > > > Review request for mesos, Anand Mazumdar and Zhitao Li. > > > Bugs: MESOS-4514 > https://issues.apache.org/jira/browse/MESOS-4514 > > > Repository: mesos > > > Description > ------- > > This doc doesn't include all the calls supported by the APIs yet. > > > Diffs > ----- > > docs/operator-http-api.md PRE-CREATION > > Diff: https://reviews.apache.org/r/49730/diff/ > > > Testing > ------- > > https://gist.github.com/vinodkone/4695c9ab2718865ff3661d485f0eed3c > > > Thanks, > > Vinod Kone > >