The POST method is used to request thatthe origin server accept the entity enclosed inthe request as a new subordinate ofthe resource identified bythe Request-URI inthe Request-Line. POST is designed to allow a uniform method to cover the following functions:
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
- Providing a block of data, such astheresultof submitting a
form, to a data-handling process;
- Extending a database through an append operation.
The actual function performed bythe POST method is determined bythe server andis usually dependent onthe Request-URI. The posted entity is subordinate tothat URI inthe same way that a fileis subordinate to a directory containing it, a news article is subordinate to a newsgroup to which itis posted, or a recordis subordinate to a database.
The action performed bythe POST method might notresultin a resource that can be identified by a URI. In this case, either 200 (OK) or204 (No Content) isthe appropriate response status, depending on whether ornotthe response includes an entity that describes theresult.
If a resource has been created onthe origin server, the response SHOULD be 201 (Created) andcontain an entity which describes the status ofthe request and refers tothe new resource, and a Location header (see section 14.30).
Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.
POST requests MUST obey the message transmission requirements set out in section 8.2.
See section 15.1.3for security considerations.
9.6 PUT
The PUT method requests thatthe enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified versionofthe one residing onthe origin server. If the Request-URI doesnot point to an existing resource, andthat URI is capable of being defined as a new resource bythe requesting user agent, the origin server can create the resource withthat URI. If a new resource is created, the origin server MUST inform the user agent via the201 (Created) response. If an existing resource is modified, either the200 (OK) or204 (No Content) response codes SHOULD be sent to indicate successful completion ofthe request. If the resource could not be created or modified withthe Request-URI, an appropriate error response SHOULD be giventhat reflects the nature ofthe problem. The recipient ofthe entity MUST NOT ignore any Content-* (e.g. Content-Range) headers thatitdoesnot understand or implement and MUST return a 501 (Not Implemented) response in such cases.
If the request passes through a cache andthe Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.
The fundamental difference betweenthe POST and PUT requests is reflected inthe different meaning ofthe Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway tosome other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed withthe request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI,it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether ornotto redirect the request.
A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate fromthe URI identifying each particular version. In this case, a PUT request on a general URI might resultin several other URIs being defined bythe origin server.
HTTP/1.1doesnot define how a PUT method affects the state of an origin server.
PUT requests MUST obey the message transmission requirements set out in section 8.2.
Unless otherwise specified for a particular entity-header, the entity-headers inthe PUT request SHOULD be applied tothe resource created or modified bythe PUT.
当前的理解put用来存储URI资源,不是是幂次的,即不重复添加。post保持资源,幂次的。The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by th