Этому посту явно не хватает картинок «было» — «стало»… (ну или подсказок, на какой минуте смотреть :)
А так начинание от Android Design Team заслуживает внимания)
Да, все верно. Если использовать call напрямую, то нужно дополнительно передать id, иначе не сделать реализацию с notifications (возможность передачи пустого id)
Использовать HTTP Basic Auth. В клиенте достаточно добавить логин и пароль в массив $CurlOptions :)
Использовать токены через HTTP-заголовки. Для получения токенов можно написать необходимый метод.
Использовать токены как параметры метода.
Сделать общий proxy-класс, в котором описать все эти методы и сделать из него RPC Server.
Казалось бы, костыль. Но! Предположим, что мы делаем апи для мобильного приложения. Набор методов уже заранее известен, они находятся в разных классах. Создаем MobileAppServer (отнаследованный от BaseJsonRpcServer), в котором собираем все методы воедино — ничего лишнего. В такой реализации доступна пост-обработка результатов этих методов, например сокрытие лишних переменных в результирующих объектах. Как-то так.
>* auto-discovery — захватывает все public методы класса? куда девать public методы не используемые в API?
Вообще не делать их public) ну или добавить в $hiddenMethods, благо protected.
>* mass-assignment?
Тут не применимо, сигнатуры методов известны:)
Касательно тестов — для конечного клиента писать не нужно, тут имелось в виду тесты к базовой реализации клиента. Код конечного клиента генерируется на основе smd-файла.
В чем отличие от REST: наличие какого-то стандартизированного механизма auto-discovery.
Предположим, что у нас есть уже веб-сервис и сгенерированный клиент на основе smd-схемы.
В веб-сервисе появились новые методы. В случае REST — нужно вручную написать к ним реализацию в клиенте.
В случае с auto-discovery — нужно всего-лишь сгенерировать нового клиента — профит.
Курить левую документацию не нужно, т.к. это JSON-RPC :)
Те, кто ругают win8 в плане интерфейса и отсутствия меню пуск — не умеют пользоваться горячими клавишами… А их прибавилось не мало.
+ Старое поведение осталось — Кнопка win — и сразу набираем то, что нам нужно)
Другой вопрос, конечно, это объяснить «родственникам», как этим всем пользоваться ;)
У меня на e6 с последней прошивкой точно такие же баги (а бывает и похуже), даже перепрошивка фениксом в refubrish не спасла. Жалею, что обновился на Belle. E6 отличный аппарат по железу и формфактору, но блин, внутренний софт расстраивает ;(
Осталось подождать, пока JetBrains в свои клёвые IDE прикрутит поддержку 1.7. А то сообщения типа «Project is likely to be of unsupported Subversion format» немного огорчают.
my.opera.com/community/forums/topic.dml?id=1316712
А так начинание от Android Design Team заслуживает внимания)
помимо этих идей или их раскрыть надо?
Казалось бы, костыль. Но! Предположим, что мы делаем апи для мобильного приложения. Набор методов уже заранее известен, они находятся в разных классах. Создаем MobileAppServer (отнаследованный от BaseJsonRpcServer), в котором собираем все методы воедино — ничего лишнего. В такой реализации доступна пост-обработка результатов этих методов, например сокрытие лишних переменных в результирующих объектах. Как-то так.
(не туда запостил)
Вообще не делать их public) ну или добавить в $hiddenMethods, благо protected.
>* mass-assignment?
Тут не применимо, сигнатуры методов известны:)
В чем отличие от REST: наличие какого-то стандартизированного механизма auto-discovery.
Предположим, что у нас есть уже веб-сервис и сгенерированный клиент на основе smd-схемы.
В веб-сервисе появились новые методы. В случае REST — нужно вручную написать к ним реализацию в клиенте.
В случае с auto-discovery — нужно всего-лишь сгенерировать нового клиента — профит.
Курить левую документацию не нужно, т.к. это JSON-RPC :)
+ Старое поведение осталось — Кнопка win — и сразу набираем то, что нам нужно)
Другой вопрос, конечно, это объяснить «родственникам», как этим всем пользоваться ;)