Specification - RETS

5.8 Optional Response Arguments
5.9 Metadata
5.10 Resources
There are no optional response arguments.
To retrieve objects the client MAY first retrieve the metadata that describes the Resources
and Objects that are available with the GetMetadata transaction described in section 12. A
full description of the Metadata Dictionary is provided in Section 11.
RETS does not require that any particular type of object be made available by a server.
However, a server MUST use a standard well-known name under which to make its data
available if a suitable well-known name is defined in the standard.
5.11 Multipart Responses
5.11.1 General Construction
As described in Section 5.3, in the case where the client has requested multiple resourceentity
or object-id values or if any object-id-list is “*”, the server MUST return a
multipart response. In the case of multipart responses, in which one or more different sets
of data are combined in a single body, a “multipart” media type field must appear in the
entity's header.
RFC 2045 describes the format of an Internet message body containing a MIME message.
The body contains one or more body parts, each preceded by a boundary delimiter line,
and the last one followed by a closing boundary delimiter line. After its boundary delimiter
line, each body part then consists of a header area, a blank line, and a body area.
Example:
HTTP/1.1 200 OK
Server: Apache/2.0.13
Date: Fri, 22 OCT 2004 12:03:38 GMT
Cache-Control: private
RETS-Version: RETS/1.0
MIME-Version: 1.0
Content-type: multipart/parallel; boundary="simple boundary"
--simple boundary
Content-Type: image/jpeg
Content-ID: 123456
Object-ID: 1
--simple boundary
Content-Type: image/jpeg
Content-ID: 123457
Object-ID: 1
Version 1.7.2 5-5