RETS (Real Estate Transaction Standard) — открытый протокол обмена данными объектов недвижимости, а запрос «rets standard small» обычно возникает у разработчиков, которым нужно подключить небольшую MLS-систему или сайт агентства к RETS-серверу без развёртывания тяжёлой инфраструктуры. Проблема в том, что полный стек RETS с авторизацией по дайджесту, сессионными cookie и XML-метаданными выглядит избыточным для маленького проекта, поэтому ищут компактный вариант реализации.
В этой статье разберём, что стоит за понятием «small» в контексте RETS, как устроен протокол, какие библиотеки подходят для лёгкой интеграции и на что обратить внимание при выгрузке листингов. Отдельно рассмотрим переход на RESO Web API, который постепенно вытесняет классический RETS.
Что такое RETS и откуда взялся термин «small»
RETS разработан организацией RESO (Real Estate Standards Organization) как единый способ передачи данных между MLS (Multiple Listing Service) и внешними системами: сайтами агентств, CRM, аналитическими сервисами. Протокол работает поверх HTTP/HTTPS и возвращает данные в компактном текстовом или XML-формате.
Термин «small» в запросах обычно означает одно из трёх: компактный формат ответа COMPACT (в отличие от XML), минимальную клиентскую реализацию для небольшого проекта или работу с малой MLS, где объём листингов невелик и полноценная ETL-инфраструктура не нужна. Во всех трёх случаях логика работы одинакова: логин, запрос метаданных, поиск, выгрузка, логаут.
RETS официально признан устаревшим: RESO рекомендует новым интеграциям использовать RESO Web API на базе OData, но множество MLS-серверов до сих пор отдают данные только через RETS.
Как устроен протокол: основные транзакции
Клиент RETS общается с сервером через набор стандартных транзакций. Понимание их последовательности важнее, чем знание конкретной библиотеки — логика везде одинаковая.
- 🔐 Login — аутентификация по HTTP Digest, получение сессионного cookie и URL-адресов остальных сервисов.
- 📋 GetMetadata — загрузка описания ресурсов, классов и полей (фактически схемы данных конкретной MLS).
- 🔍 Search — запрос листингов с фильтрами на языке DMQL (или DMQL2).
- 🖼️ GetObject — скачивание фотографий и документов объектов.
- 🚪 Logout — завершение сессии, обязательное для корректной работы лимитов сервера.
Обратите внимание: названия ресурсов, классов и системные имена полей у каждой MLS свои. Универсального маппинга не существует — схему всегда нужно читать через GetMetadata конкретного сервера, а не копировать из чужих примеров.
Компактный формат COMPACT и COMPACT-DECODED
Параметр Format в поисковом запросе определяет вид ответа. Для «лёгких» интеграций чаще всего выбирают COMPACT-DECODED — табличный текст, где поля разделены табуляцией, а значения уже раскодированы в читаемый вид (например, вместо кода статуса возвращается его текстовое обозначение).
Типичный поисковый запрос выглядит так:
SearchType=Property&Class=RES&Query=(Status=|Active)&Format=COMPACT-DECODED&Limit=100Имена классов (Property, RES) и значения статусов здесь приведены как пример — у вашей MLS они могут отличаться. Сверяйте их с метаданными сервера перед запуском выгрузки.
Минимальная реализация для небольшого проекта
Для малого объёма данных вам не нужен полноценный ETL-конвейер. Достаточно скрипта, который раз в сутки (или чаще, если позволяют условия MLS) выполняет инкрементальную выгрузку по дате изменения записей. Ключевой принцип — никогда не тянуть всю базу целиком, если можно запросить только изменившиеся листинги.
Из готовых инструментов чаще всего упоминают библиотеку PHRETS для PHP и rets-client для Node.js. Обе берут на себя дайджест-авторизацию, разбор COMPACT-ответов и работу с сессией. Если ваш стек другой, ищите клиент под него — самостоятельная реализация Digest-аутентификации и парсинга метаданных заметно увеличит сроки.
☑️ Чек-лист первой инкрементальной выгрузки RETS
⚠️ Внимание: многие RETS-серверы ограничивают число одновременных сессий и размер одного ответа. Если скрипт падает с обрывом соединения, проверьте, не забыли ли вы Logout в предыдущем запуске и не превышает ли выгрузка лимит записей за один запрос.
Типичные ошибки при подключении
Больше всего вопросов вызывает этап авторизации. RETS использует HTTP Digest, и если клиент отправляет Basic-авторизацию или не передаёт сессионный cookie в последующих запросах, сервер отвечает ошибкой 401. Вторая частая проблема — неверные имена полей в DMQL-запросе: запрос с несуществующим системным именем возвращает ошибку 20200 (Unknown Query Field) или похожий код.
| Симптом | Вероятная причина | Что проверить |
|---|---|---|
| Ошибка 401 при логине | Неверный тип авторизации или учётные данные | Digest-режим в клиенте, логин/пароль, user-agent |
| Код 20200 в ответе Search | Поле из запроса отсутствует в метаданных | Системные имена полей через GetMetadata |
| Обрыв выгрузки на больших выборках | Превышен лимит записей сервера | Параметры Limit/Offset, постраничность |
| Отказ в новых сессиях | Не закрыты предыдущие сессии | Вызов Logout, таймауты сессий |
| Коды вместо текста в полях | Используется COMPACT вместо COMPACT-DECODED | Параметр Format в запросе |
Сохраняйте сырой ответ GetMetadata в файл при первой настройке — это избавит от лишних запросов к серверу на этапе отладки и даст актуальный справочник полей.
RETS или RESO Web API: что выбрать сейчас
Если MLS предлагает оба варианта, для нового проекта разумнее смотреть в сторону RESO Web API: это REST-подход с OAuth 2.0 и JSON вместо сессий и COMPACT-таблиц. Код интеграции получается заметно проще, а стандартизированные поля Data Dictionary снижают зависимость от локальных схем конкретной MLS.
Однако выбор не всегда за вами: часть MLS продолжает работать только по RETS, и тогда компактный RETS-клиент остаётся единственным вариантом. Практичная стратегия — изолировать слой получения данных за собственным интерфейсом, чтобы при миграции MLS на Web API переписать только адаптер, а не всю систему.
Почему RETS считается устаревшим
Протокол спроектирован в конце 1990-х: сессионная модель, собственный язык запросов DMQL и текстовый формат COMPACT плохо сочетаются с современными REST-практиками. RESO официально перевела RETS в статус устаревшего и развивает вместо него Web API на базе OData 4.0. При этом фактическая поддержка RETS на серверах MLS сохраняется, поэтому навык работы с ним остаётся востребованным.
Для небольшой интеграции достаточно готового RETS-клиента, инкрементальной выгрузки по дате изменения и корректного закрытия сессий — полноценная инфраструктура не нужна.
FAQ: частые вопросы по RETS
Что означает «small» в контексте RETS?
Единого официального «малого» стандарта RETS не существует. Под этим обычно понимают компактный формат ответа COMPACT, минимальную клиентскую реализацию или работу с небольшой MLS. Базовый протокол во всех случаях один и тот же.
Можно ли подключиться к RETS без готовой библиотеки?
Технически да — это обычные HTTP-запросы. Но придётся самостоятельно реализовать Digest-аутентификацию, управление сессионными cookie и разбор COMPACT-ответов, что заметно увеличивает трудозатраты. Для большинства проектов готовый клиент оправдан.
Почему сервер возвращает коды вместо понятных значений полей?
Вы используете формат COMPACT. Переключите параметр Format на COMPACT-DECODED — сервер сам подставит текстовые расшифровки справочных значений.
Как часто можно делать выгрузки?
Это определяется правилами конкретной MLS, а не протоколом. Уточните лимиты в соглашении о доступе к данным и используйте инкрементальные запросы по дате изменения, чтобы не нагружать сервер полными выгрузками.
Стоит ли начинать новый проект на RETS?
Если MLS поддерживает RESO Web API — начинайте с него. RETS выбирайте только когда другого способа получить данные нет, и сразу проектируйте код так, чтобы слой доступа к данным можно было заменить.