проверка циклических ссылок и поддержка типов может быть добавлена, ChALkeRx прав, тут в первую очередь интересен сам подход, за счет которого достигается 200-кратное ускорение по сравнению с любой реализацией с поддержкой типов или без

Из статьи:

поэтому преимущество в производительности достигаются в основном при необходимости повторного клонирования объектов с одинаковой структурой.

Решение у нас не самое элегантное) Мы просто переопределяем метод прототипа AbstractQuery.prototype.handleSelectQuery и для raw queries используем fast-clone. Ещё, к стати, если говорить о Sequelize, мы используем адаптер для БД mysql2 вместо стандартного mysql, т.к. он более быстро разбирает протокол.

Оптимизация интересная — Вы правы. О том что она делает можно прочитать в статье которую я привел — http://jayconrod.com/posts/52/a-tour-of-v8-object-representation в секции In-object slack tracking. Если в кратце, то она обычно используется чтобы вернуть объект к представлению в виде класса из хэш-таблицы, в которую v8 переводит его, например, после удаления какого-нибудь свойства.

Добавил в тест Object.assign, он не попал туда именно из-за отсутствия поддержки рекурсии, но скорость его также, к сожалению, значительно ниже.

Простой пример, в последний версиях Chrome и FF

JSON.stringify({a: 'a', 1: 1});
{"1":1,"a":"a"}

в PHP

echo json_encode(['a' => 'a', 1 => 1]);
{"a":"a","1":1}

Я прочитал достаточно внимательно. Вы пишете:

Почему именно JSON а не простой serialize PHP? Выбор в пользу JSON упал не случайно, поскольку это очень популярный формат сериализации, с которым будет легко работать не только в PHP, но и в любых других популярных языках программирования, таких как Java. Наша реализация должна быть предельно легко переносима на другие платформы и с использованием JSON-сериализации это будет сделать проще всего.

То что вы сортируете массив по ключам перед кодировкой его в JSON, ровно никак не гарантирует вам то что в JSON-е они буду иметь тотже порядок, вот выдержка из спецификации:

An object is an unordered set of name/value pairs.

Другими словами, hash полученный Вами в PHP и, например, в Java теоретически может отличаться, несмотря на одинаковую сортировку ключей перед кодированием в JSON.

JSON нельзя использовать для сериализации в подобных целях — он не гарантирует порядок сортировки полей в объекте (http://json.org/) Всё зависит от реализации библиотеки для конкретного языка.

Так это, действительно, если нужно расшарить какой-то объект между классами, зачем парится и использовать паттерн Registry martinfowler.com/eaaCatalog/registry.html, лучше его наверно в переменную $GLOBALS записать.

Переменная $_POST содержит исходные данные запроса, и не предназначена для того, чтобы в неё писали что-то, в то время как с лёгкой руки программистов Yii она активно меняется, в том числе и самим фреймворком.
Почему это плохо — один из примеров, представим что у нас есть система которая логирует обращения к сервису, а затем выводит эти логи пользователям данного сервиса, чтобы они могли проконтролировать насколько верно их приложение работает с API. Но при такой модели работы с переменной $_POST в ней может оказаться всё что угодно, ещё до того как она будет записана в базу. Естественно можно извернуться и записывать всегда нескомпроментированные данные, но я повторяю — это плохой дизайн.

Теперь последний раз по поводу $data = $_POST на этом месте должно быть что-то вроде $data = $this->getPost(), но даже в простом присваивании переменной $_POST к $data есть смысл, если в дальнейшем будет написано что-то вроде $data['user_id'] = Yii::app()->user->getId();

    if (isset($_POST) && ($data = $_POST)) { // проверяем отправлен ли POST запрос 
        $data['user_id'] = Yii::app()->user->getId();
        $model->attributes = $data; // пишем в модель новые атрибуты
        if ($model->save()) { // проверяем атрибуты, если валидны - то сохраняем
            $this->redirect(array('view', 'id' => $model->id));
        }
    }

или что-то в этом духе, в общем, я не вижу смысла это больше обсуждать.

Если есть желание по коду подискутировать, давайте обсудим лучше какие-то сложные/спорые моменты в самой библиотеке.

Никто не спорит, что тонкие контроллеры — это хорошо, но чем по вашему «обычные контроллеры» отличаются от обрабатывающих REST-запросы, если они выполняют одну и туже функцию — получают данные и добавляют запись. В то время, как вся логика добавления записи может и должна быть зашита внутри модели, а сложная логика обработки в сервис.

А что Вы собираетесь проверять на уровне роутов? Я в тексте достаточно чётко объяснил, что экшен по GET запросу отдает форму, по POST добавляет запись.

Метод isPost добавлен для семантики, в месте с методами isPut и isDelete которые обдадают расширенной функциональностью по ср. с базовыми — github.com/paysio/yii-rest-api/blob/master/library/rest/controller/Behavior.php. Да и просто так писать меньше =)

($data = $_POST) в таком виде действительно особого смысла не имеет, но присутствует здесь т.к. работать с переменной $_POST напрямую — плохая практика, которая, между тем, в Yii используется. Хорошим примером является предоставление единой точки доступа, как, например, тут — github.com/zendframework/zf2/blob/master/library/Zend/Http/Request.php

По поводу версионности — спорный вопрос сама версионность или её реализация?
Я считаю вполне приемлемым то, что версионность поддерживается на уровне роутов, т.к. изменение нескольких параметров не должно приводить к смене версии, а новый код естественно будет писаться в новых модулях/контроллерах/экшенах, которые внутри можно удобно именовать, а снаружи просто прилинковать с соответствующей версией.

В приведенной ссылке на How-To по REST API, не идет речь о том чтобы добавить API к существующей бизнес-логике, там просто приведен пример построения ответов. Ошибки приложения (эксепшены, ворнинги) там также никак не обрабатываются, ошибки валидации форм отдаются в html и без возможности определения типа ошибки. Да и просто много оверхеда по приведенному коду.
Но как тема для размышлений — вполне нормальный пример.

Всё — для общего дела! =)