> 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
> 
>

Reply via email to