Atom API POST request validation/interpretation rules -- Atom format
See AtomApiTest, AtomApiTestDiscussion
Request
Children of
entry:
id:
-
MUST NOT be present.
link:
-
MAY be present.
-
Some servers MAY use this to determine the URI of the created resource. Relative URLs are to be interpreted relative to xml:base.
title:
-
MUST be present.
-
may be empty, to explicitly indicate "no title". Servers SHOULD NOT try to generate a title is one is not provided. (Note: syndication clients MAY, but that's a different scenario)
-
the type attribute MAY be present. Default is "text/plain" If present, it MUST represent a mime type that the server supports
-
the mode attribute MAY be present. Default is "xml". If present, it must be "xml", "base64", or "escaped".
summary:
-
MAY be present. If not present, indicates the server is welcome to produce its own summary (perhaps by truncation).
-
the type attribute MAY be present. Default is "text/plain" If present, it must represent a mime type that the server supports
-
the mode attribute MAY be present. Default is "xml". If present, it must be "xml","base64", or "escaped".
content:
-
MUST be present.
-
MAY be empty, to explicitly indicate "no content"
-
the type attribute MAY be present. Default is "text/plain" If present, it must represent a mime type that the server supports
-
the MODE attribute may be present. Default is "xml". If present, it must be "xml","base64", or "escaped".
issued:
-
MUST be present. May be empty, in which case it means "now" in the timezone of the server
modified:
-
MUST NOT be present on a POST. Set by server.
created:
-
MUST NOT be present on a POST. Set by server.
author:
-
MAY be present. If not present, the server determines the author based on authentication.
contributor:
-
MAY be present. If not present, there are no contributors
generator:
-
MUST be present. Indicates the code base used to create this request.
-
MUST contain either a valid URL or a valid email address
-
MUST contain a version number
Response
Expected status codes from a POST are 201, 303, 400, and 500. 401, 404, and 410 are also possible.
201 specifies the location of the resource created. Response includes a Location: header with the URI of the created resource, i.e. the URI used to edit the entry (as opposed to the URI used to display the content). The body of the response will contain the entry "filled in" with time stamps and any other data the server choses to reveal. This must contain enough information to enable a client to issue a subsequent PUT to this location. Note: the server may chose to omit the content in the response, particularly if it is large.
303 The body of this response does not contain the filled in Entry, but the filled in Entry can be found under a different URI and SHOULD be retrieved using a GET method on that resource. The different URI SHOULD be given by the Location field in the response.
400 indicates that the server believes that that data sent constitutes an invalid request. A short description of the error will appear on the status line itself. A longer description (in plain text format) will appear in the body.
500 indicates that the server detected an internal error on the server processing this request (such as an unhandled exception). A short description of the error will appear on the status line itself. A longer description (in plain text format) will appear in the body.
