>From https://tools.ietf.org/html/rfc2616#section-9.5
The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result. In this case I think the 200 OK code is most appropriate since the server generates a signed voucher as a result of the POST and returns it. The voucher is not identified by a URI. - max > On Jun 4, 2017, at 7:42 PM, Michael Richardson <[email protected]> wrote: > > > Max, in section 3.3 we document the contents that the Registrar will POST to > the MASA's /requestvoucher. > > In section 3.4 we say: > 3.4. Voucher Response > > ... > If the the join operation is successful, the server response MUST > contain an HTTP 200 response code. The server MUST answer with a > suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. > > It seems that since we are using POST, that we ought to answer with an HTTP > 201 response code, and include a Location: header at which the voucher could > be accessed later on. I am not sure if I'm arguing for returning just the > 201, and expect the Registrar to do a GET, although that would be more > correct. > > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
