Search

RETS Change Proposal 49: Remove Multipart from GetObject
Author: Dave Dribin
Organization: Center for REALTORŪ Technology
Telephone:
Address: 430 N. Michigan Ave., Floor 6, Chicago IL, 60611-4087
Email: dribin@crt.realtors.org
Status: Proposal
Date: 11/07/2003
Proposal Version: 1.7
1. Synopsis
Remove multipart MIME responses from the GetObject transaction.
2. Rationale
The multipart MIME response allows multiple images to be returned in one HTTP request. However, this requires special handling on the server to create a multipart response, as well as special handling on the client to pull apart the objects. This is presumable for performance reasons. HTTP already provides performance optimizations for multiple requests using persistent connections and pipelining. RETS should use these existing HTTP mechanisms.
3. Proposal
By removing multipart responses, all GetObject responses MUST contain only one object. This means only one object may be requested per transaction. However, the ability to retrieve all objects for a resource entity (using an object ID of "*") is still desired. Rather than return the actual objects, an object ID of "*" returns a list of valid objects in an XML response. The client will the be responsible for issuing a new GetObject transaction per object returned.

Section 5.3 shall be changed to:

  ID               = resource-set
 resource-set     = resource-entity [ ":" object-id ]
 resource-entity  = 1*ALPHANUM
 object-id        = 1*DIGIT | "*"

Notable changes from 1.5:

  • Only one resource-set
  • Only one object-id (no object-id-list)

For transactions with an object-id with a number, the server MUST respond with the appropriate Content-Type.

For transaction with an object-id of "*", the server MUST respond with the following XML response:

<?xml version="1.0" ?>
<RETS ReplyCode=quoted-reply-code
     ReplyText=quoted-string>
 <GetObjectResponse>
   <ObjectList>
   *(object-tag)
   </ObjectList>
 </GetObjectResponse>
</RETS>

object-tag =
<Object>
 <Id>1*DIGIT</Id>
 *<Location>URL</Location>
 *<Default/>
</Object>

An example response for 3 objects is as follows:

<?xml version="1.0" ?>
<RETS ReplyCode="0" ReplyText="Success"
 <GetObjectResponse>
   <ObjectList>
     <Object>
       <Id>1</Id>
       <Location>http://www.example.com/property.jpg</Location>
     </Object>
     <Object>
       <Id>2</Id>
       <Default/>
     </Object>
     <Object>
       <Id>3</Id>
     </Object>
   </ObjectList>
 </GetObjectResponse>
</RETS>

4. Development Impact
This should greatly simplify development as clients and servers need not encode and decode using a non-standard MIME type. Existing HTTP 1.1 servers already support persistent connections and pipelining as it is part of the HTTP 1.1 specification. Clients need not implement persistent connections and pipelining. In fact most web browsers do not implement pipelining, however most do use persistent connections.

Clients that only retrieved one object at a time will require no modifications. Clients that retrieved multiple resource entities and objects in one transaction must split the request into multiple individual transactions. Clients using the "*" notation must be modified to parse an XML response rather than a multipart response.

5. Compatibility
For GetObject transactions that only returned a single object, this is fully backward compatible. Transactions that used to return multiple objects using multipart are no longer compatible.
6. Proof/Need of Concept Examples
None.