> On June 22, 2015, 8:04 p.m., Ben Mahler wrote: > > Adding this seems good since it's agnostic to how it is used. But for > > reservations specifically, any reason not to use just BadRequest? > > > > From what I can tell, this is generally used for conditional requests > > (based on headers or some other conditionals): > > http://stackoverflow.com/a/5369582 > > What will the pre-conditions be for /reserve? If the request does not > > contain explicit pre-conditions, it seems a little non-idiomatic to return > > 412..? > > Michael Park wrote: > I was hoping to keep `BadRequest` to situations where the user has > provided bad/invalid arguments. e.g. invalid JSON format, missing parameters, > invalid resources, etc. > > I was aiming to use `PreconditionFailed` to represent the case where the > user have provided perfectly valid arguments, but we don't currently have > sufficient resources to satisfy the request. The precondition here is whether > we have sufficient resources or not. I'm of course open to using `BadRequest` > with an explanation or what went wrong, or perhaps using a different status. > (e.g. `Conflict` was suggested) > > I'm not an expert on HTTP statuses and so I don't have a strong stance > here, do you have a strong opinion or stance on this? I'm really open to > anything. > > Alexander Rukletsov wrote: > I think we should definitely distinguish between invalid JSON format, > failed authorization (not in MVP) and inability to satisfy a valid request. > For the latter case, I'm not sure `Conflict` is good choice, I would propose > `403 Forbidden`.
Thanks Alex! `403 Forbidden` sounds reasonable to me as well. - Michael ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/35714/#review88839 ----------------------------------------------------------- On June 22, 2015, 5:08 a.m., Michael Park wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/35714/ > ----------------------------------------------------------- > > (Updated June 22, 2015, 5:08 a.m.) > > > Review request for mesos, Adam B and Jie Yu. > > > Repository: mesos > > > Description > ------- > > Needed in subsequent patch for /reserve master endpoint. > > > Diffs > ----- > > 3rdparty/libprocess/include/process/http.hpp > e47cc7afbc8110759edf25a2dc05d09eda25c417 > > Diff: https://reviews.apache.org/r/35714/diff/ > > > Testing > ------- > > `make check` > > > Thanks, > > Michael Park > >
