I have been working with the RESTful API within NSX for vSphere a bit lately. I have been standing a few environments up with a python script that makes sequential API requests to the NSX manager. This has been pretty damned fun. What I have learnt from some of the members of my team (Dmitri Kalintsev and Thomas Kraus) is that knowing what type of function you are performing is important to know what code to expect. Once you establish the expected result of a CONFIGURE or CREATE you can make the python script smart accordingly.

For my reference and for the upcoming posts I am going to cover some status codes.

201: The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.

204: The server has fulfilled the request but does not need to return an entity-body, and might want to return updated meta information. The response MAY include new or updated meta information in the form of entity-headers, which if present SHOULD be associated with the requested variant. If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent’s active document view, although any new or updated meta information SHOULD be applied to the document currently in the user agent’s active view. The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.

One thought on “SPARK: HTTP Status codes

Leave a Reply

Your email address will not be published. Required fields are marked *