Комментарии 92
Это не может не радовать, молодцы! Жаль только, что Python нет.
Я правильно понимаю, что это тоже самое, что и Core API и Sync API у Dropbox www.dropbox.com/developers/core/docs?
Скажите, не появилось возможности upload'а файла по частям? А то при download'е можно использовать Range заголовки, а что делать если к примеру за один раз не получается залить файл на Яндекс.Диск?
О, да это же Рон Уизли! Только волшебная палочка мелковата :)
А как будет поступать Яндекс в следующей ситуации.
Например, владелец прав (копираст), сообразил, что можно автоматизировать процесс проверки наличия копий контента на Яндекс.Диске, используя волшебную функцию дедупликации. Шлёт запросы с md5 sha-256 и размером файла яндекс.Диску, а тот и говорит что, файл уже есть или его ещё нет.
Если файл есть, то владелец прав пишет письмо Яндексу, с просьбой удалить такой файл (т.к. контент распространяется, например, только через iTunes). Как будет поступать Яндекс?
Например, владелец прав (копираст), сообразил, что можно автоматизировать процесс проверки наличия копий контента на Яндекс.Диске, используя волшебную функцию дедупликации. Шлёт запросы с md5 sha-256 и размером файла яндекс.Диску, а тот и говорит что, файл уже есть или его ещё нет.
Если файл есть, то владелец прав пишет письмо Яндексу, с просьбой удалить такой файл (т.к. контент распространяется, например, только через iTunes). Как будет поступать Яндекс?
Это могут файлы пользователя, купленные в itunes и положенные потом в Диск. Так как таким образом нельзя узнать у кого именно такой файл есть (или был, но был удален), то такой жалобы как мне кажется быть не может.
Все законные жалобы мы обрабатываем законным образом. Это касается файлов, которые доступны всем (опубликованы)
Все законные жалобы мы обрабатываем законным образом. Это касается файлов, которые доступны всем (опубликованы)
Интересная юридическая коллизия возникает.
Т.е. допустим мы знаем что на серверах яндекса лежит файл контрольная сумма которого совпадает с контрольной суммой файла, который мы знаем что точно не легальный (и можем это доказать).
Допустим контрольная сумма допускает колизии в очень редких случаях.
Т.е. о одной стороны мы с очень большой вероятностью знаем, что какой-то пользователь залил на сервер яндекс-а наш «незаконный» файл. С другой стороны доказать 100% это не можем, можем говорить о вероятности.
По хорошему суд должен приписать яндексу проверить дейсвительно ли файл является «нашим» и если да то «выдать» пользователя.
Т.е. допустим мы знаем что на серверах яндекса лежит файл контрольная сумма которого совпадает с контрольной суммой файла, который мы знаем что точно не легальный (и можем это доказать).
Допустим контрольная сумма допускает колизии в очень редких случаях.
Т.е. о одной стороны мы с очень большой вероятностью знаем, что какой-то пользователь залил на сервер яндекс-а наш «незаконный» файл. С другой стороны доказать 100% это не можем, можем говорить о вероятности.
По хорошему суд должен приписать яндексу проверить дейсвительно ли файл является «нашим» и если да то «выдать» пользователя.
утверждение что файл «незаконный» уже спорное :) однако точный юридический спор я лично вести не готов :)
который мы знаем что точно не легальный (и можем это доказать).
Это как?
Не думали организовать нечто вроде p2p для публично доступных файлов? Например на отдыхе в Таиланде всяко скорость и задержки не порадуют до ваших серверов. А если есть пользователь Яндекс диска в соседнем городе с аналогичным файлом в публичном доступе (например свежая прошивка для iOS), то тянуть я буду уже у него через Тайского провайдера с нормальной местной скоростью. Извиняюсь если такая возможность есть и я упустил упоминание о ней.
Также в теме про консольный клиент для Linux интересовался планируете ли запилить дроплет (виджет или расшаривание перетаскиванием на иконку в трее) для десктопного приложения. Веб-виджет конечно хорошо, но хочется еще лучше. Поделитесь планами?
Также в теме про консольный клиент для Linux интересовался планируете ли запилить дроплет (виджет или расшаривание перетаскиванием на иконку в трее) для десктопного приложения. Веб-виджет конечно хорошо, но хочется еще лучше. Поделитесь планами?
C интересом слушал этот доклад.
Вот чего не хватает в API:
На сторонний сервис (который владелец диска авторизовал) встраивает на свою страничку форму загрузка файла в яндексдиск пользователя.
Пользователь со странички стороннего сервиса загружает файл в диск, а ссылку на него получает себе.
Зачем это нужно: наш суперсервис даёт, допустим, 100МБ места на своих железках и возможность интеграции с (загрузки файлов в) ЯД.
таким образом: наш сервис не занимается непрофильной фигнёй, а пользователь имеет возможность грузить на ЯД. Круг замкнулся, при этом суперсервису на надо сначала загружать файлик себе, а «от себя» в ЯД.
Вот чего не хватает в API:
На сторонний сервис (который владелец диска авторизовал) встраивает на свою страничку форму загрузка файла в яндексдиск пользователя.
Пользователь со странички стороннего сервиса загружает файл в диск, а ссылку на него получает себе.
Зачем это нужно: наш суперсервис даёт, допустим, 100МБ места на своих железках и возможность интеграции с (загрузки файлов в) ЯД.
таким образом: наш сервис не занимается непрофильной фигнёй, а пользователь имеет возможность грузить на ЯД. Круг замкнулся, при этом суперсервису на надо сначала загружать файлик себе, а «от себя» в ЯД.
Честно говоря, не удалось осознать схемы. «Суперсервис» что делает?
Спасибо за комментарий.
Постараюсь описать кейс с другой стороны.
Допустим мы интегрируем ЯД с форумом. (напр. отдавать аттачи из ЯД).
Как можно сделать сейчас (с текущим API): пользователь загружает файлы на сервер форума, а сервер или в контексте этого же запроса (или, например, по крону) на ЯД, получает публичную ссылку и её раздаёт.
Что мне кажется кривым: необходимость сначала загрузить файл себе, а потом в ЯД.
Как я бы решал проблему: по API получать уникальный уникальный адрес (action="..." в форме), по которому сторонний пользователь может загрузить файл в ЯД.
Надеюсь, я довольно подробно описал проблему. Если необходим «самый конкретный кейс», с которым я столкнулся, интегрируя дропбокс с «суперсервисом», пишите, я его подробно опишу в ЛС.
Постараюсь описать кейс с другой стороны.
Допустим мы интегрируем ЯД с форумом. (напр. отдавать аттачи из ЯД).
Как можно сделать сейчас (с текущим API): пользователь загружает файлы на сервер форума, а сервер или в контексте этого же запроса (или, например, по крону) на ЯД, получает публичную ссылку и её раздаёт.
Что мне кажется кривым: необходимость сначала загрузить файл себе, а потом в ЯД.
Как я бы решал проблему: по API получать уникальный уникальный адрес (action="..." в форме), по которому сторонний пользователь может загрузить файл в ЯД.
Надеюсь, я довольно подробно описал проблему. Если необходим «самый конкретный кейс», с которым я столкнулся, интегрируя дропбокс с «суперсервисом», пишите, я его подробно опишу в ЛС.
Все что я хочу — чтобы Яндекс.Диск не ограничивал время хранения файлов 90 днями с момента последнего скачивания — и этого достаточно
Давайте будем говорить прямо: WebDAV — это странная, нелогичная, избыточная в синтаксисе, медленная, не вполне однообразно стандартизированная и по-разному поддерживаемая разными клиентами и серверами хрень. Всякие там гугл-драйвы, дропбоксы и прочие это осознали с самого начала и сразу сделали нормальный API, а Яндекс изначально почему-то решил что вот у предыдущих 100500 пытавшихся не вышло, а у него выйдет. Попытка сразу была провальная (насколько я помню, первым попавшимся вебдав-клиентом даже к яндекс.диску не прицепишся в виду кастомной авторизации) и чего было её городить — непонятно.
Ах, когда уже научатся в статьях говорить правду: «Ошиблись в первой версии, а теперь всё сделали правильно», так нет, пытаются сохранить лицо, ещё больше его теряя.
Ах, когда уже научатся в статьях говорить правду: «Ошиблись в первой версии, а теперь всё сделали правильно», так нет, пытаются сохранить лицо, ещё больше его теряя.
WebDAV выполнил свою функцию на первом этапе, сейчас мы двигаемся дальше. Сложно назвать ошибкой то, что без проблем используется десятки миллионов раз в сутки. :)
Вы знаете мне, как автору библиотеки для WebDAV под С++, .NET, Java и JavaScript, использованной потом в двух десятках проектов для связи с полусотней разных WebDAV — серверов назвать это ошибкой ну совсем не сложно.
-XML-ный синтаксис WebDAV хуже по наглядности чем JSON и хуже по объему\скорости работы чем, например, Protobuf.
-WebDAV отвратительно реализован в Windows.
-Для авторизации каждый придумывает свои велосипеды — кто-то использует базовую, кто-то OAuth, Майкрософт вон вообще куки берёт из веб-сессии, в итоге найти вебдав-клиент, совместимый со всеми серверами — невозможно
-Набор полей в ответе просто непредсказуемо меняется в разных реализациях сервера.
-Люди умудряются использовать собственные форматы времени.
-Простейшая вещь — дисковая квота — описана несколькими разными RFC и реализуется то так, то эдак (а чаще всего — никак).
-Часть серверов требует чтобы URL заканчивался слэшом, часть — чтобы ни в коем случае не заканчивался, часть работает так и так.
-Загрузка файлов на некоторых серверах через POST, на других — через PUT, на третьих и так и так.
-Докачка где-то есть, а где-то нет.
-На счет дедубликации вы и сами сказали.
…
Я думаю задавшись целью мог бы написать ещё пару десятков пунктов, за годы использования накопилось. В общем, Яндекс сделал всё, чтобы на первом этапе внедрения технологии затормозить её использование. Может быть вам было нужно время для развития инфраструктуры и вы хотели притормозить приток пользователей? Тогда да, всё ок.
В любом случае — удачи вашему API, вот теперь вы всё делаете верно.
-XML-ный синтаксис WebDAV хуже по наглядности чем JSON и хуже по объему\скорости работы чем, например, Protobuf.
-WebDAV отвратительно реализован в Windows.
-Для авторизации каждый придумывает свои велосипеды — кто-то использует базовую, кто-то OAuth, Майкрософт вон вообще куки берёт из веб-сессии, в итоге найти вебдав-клиент, совместимый со всеми серверами — невозможно
-Набор полей в ответе просто непредсказуемо меняется в разных реализациях сервера.
-Люди умудряются использовать собственные форматы времени.
-Простейшая вещь — дисковая квота — описана несколькими разными RFC и реализуется то так, то эдак (а чаще всего — никак).
-Часть серверов требует чтобы URL заканчивался слэшом, часть — чтобы ни в коем случае не заканчивался, часть работает так и так.
-Загрузка файлов на некоторых серверах через POST, на других — через PUT, на третьих и так и так.
-Докачка где-то есть, а где-то нет.
-На счет дедубликации вы и сами сказали.
…
Я думаю задавшись целью мог бы написать ещё пару десятков пунктов, за годы использования накопилось. В общем, Яндекс сделал всё, чтобы на первом этапе внедрения технологии затормозить её использование. Может быть вам было нужно время для развития инфраструктуры и вы хотели притормозить приток пользователей? Тогда да, всё ок.
В любом случае — удачи вашему API, вот теперь вы всё делаете верно.
полнейший бред. как только у меня появился яндекс диск я подрубил его к своему линукс серверу через davfs2 без каких либо проблем вообще. И вот уже пару лет так работает, сервер бекапов у меня тоже так настроен. На пхп элементарная реализация вебдава, у меня сайты бекапят сами себя в яндекс диск вместе с дампами базы. Ещё куча плюсов есть, главная из которых — низкий порог вхождения, которые есть у вебдава. У любой технологии есть плюсы и минусы. Я считаю решения яндекса использовать вебдав правильным решением, по крайней мере для меня было это идеальным решением.
Есть и еще хорошие новости!
Практически незаметно в сети появился MegaSync — бетта Windows-клиента для Mega. Приложение очень даже ничего! Начал активно пользоваться мегой…
Практически незаметно в сети появился MegaSync — бетта Windows-клиента для Mega. Приложение очень даже ничего! Начал активно пользоваться мегой…
Хмм… Посмотрел SDK для C# — там в DiskItemInfo есть IsPublished.
Хочется, чтобы в ответе сервера по обычному PROPFIND (с depth 1 — получение контента директории) тоже было это самое isPublished, а пока, насколько я понимаю, можно только отдельно сделать запрос для каждого файла. Очень неудобно.
Можно ли надеяться на то, что в ближайшее время появится этот тэг в XML ответе?)
Хочется, чтобы в ответе сервера по обычному PROPFIND (с depth 1 — получение контента директории) тоже было это самое isPublished, а пока, насколько я понимаю, можно только отдельно сделать запрос для каждого файла. Очень неудобно.
Можно ли надеяться на то, что в ближайшее время появится этот тэг в XML ответе?)
1. Читаем документацию по API Диска: api.yandex.ru/disk/doc/dg/reference/publish.xml
2. Запоминаем, что искомое свойство –
3. Читаем документацию по PROPFIND: webdav.org/specs/rfc4918.html#rfc.section.9.1.6
4. Формируем запрос на стандартные свойства и публичную ссылку:
5.…
6. PROFIT!
2. Запоминаем, что искомое свойство –
<public_url xmlns="urn:yandex:disk:meta"/>3. Читаем документацию по PROPFIND: webdav.org/specs/rfc4918.html#rfc.section.9.1.6
4. Формируем запрос на стандартные свойства и публичную ссылку:
<D:propfind xmlns:D="DAV:">
<D:allprop/>
<D:include>
<public_url xmlns="urn:yandex:disk:meta"/>
</D:include>
</D:propfind>
5.…
6. PROFIT!
1. Вы имеете ввиду, что к стандартному PROPFIND с Depth 1 нужно добавить тот же самый XML, что и для получения свойства расшарен/не расшарен индивидуального файла?) И тогда в итоге сервер в ответ включит еще и признак публичности?
2. Это проверенный способ или просто предположение?
2. Это проверенный способ или просто предположение?
Это вам ответил разработчик webdav-компонента Яндекс.Диска, если что.
1. Я имею в виду, что PROPFIND без тела равносилен PROPFIND/allprop без инклюдов, и что инклюдить можно любые свойства. Одно из доступных документированных свойств – публичная ссылка. Когда файл не опубликован, это свойство имеет код 404, а когда опубликован – содержит саму ссылку.
2. Это то, как оно должно работать по стандарту. Я проверил – работает.
2. Это то, как оно должно работать по стандарту. Я проверил – работает.
Это очень смелое утверждение, что файлы одинаковой длинны с одинаковым значением хеш функции посчитанной по нему — это один и тот же файл. Не боитесь что первые исполняемые файлы популярных дистрибутивов будут залиты злоумышленниками? Включение вируса в большой exe/dll файл может пройти совершенно незаметно для хеша и размера.
Вычисляется два разных хэша + есть проверка по размеру. Думаю, сложно будет незаметно внедрить вирус.
Поделитесь какие? Сразу и проверим.
В изначальном посте есть ссылка на документацию: api.yandex.ru/disk/doc/dg/reference/put.xml
Проверьте, мы проверили на нескольких миллиардах файлов пока. :)
Проверьте, мы проверили на нескольких миллиардах файлов пока. :)
Они ведь две хеш-функции считают
Наверное стоит объяснить мою обеспокоенность. Вирус — очень небольшая программа, скажем её размер — 20 килобайт. Размер файла не рассматриваем, потому как тело вируса будет заменять байты носителя. Таким образом вопрос сводится к вероятности того, что 2 хеш функции не заметят 20 килобайт в файле Visual Studio 2013 Original MSDN.iso размером несколько гигабайт. Невероятно? Возможно. Никто не будет хранить большие дистрибутивы в облаке? Сомнительно. Я бы предпочёл иметь галку «не использовать дедупликацию» иначе все пользователи сервиса играют в рулетку, хотя, признаюсь, возможность «проиграть» весьма невелика.
вероятности того, что 2 хеш функции не заметят 20 килобайт
Во-первых хеш-функция не может не заметить кусок файла, так как она проходится по всем байтам.
Во-вторых, давайте посчитаем
md5 – 128 bit
sha256 – 256 bit
Вероятность коллизии (если размер файла известен) – 2^-384. В десятичной записи это примерно 114 нулей после запятой перед первой значимой цифрой.
У хэшей лавинный эффект, так что даже если вирус будет однобайтным хэши изменятся, и если для одного еще можно поискать коллизию, то чтобы совпало сразу 2, тем более на таком здоровом файле, это малореально, проще делать вирусы эксплуатирующие дырки в софте, далеко не все вовремя обновляются.
Ага, и даже если выйдет смастерить такой файл, то как его загрузить если работает дедупликация?)
Шифрование добавьте в API. Я теперь доверяю только стораджам с шифрованием.
А что конкретно вы имеете ввиду? Все соединения с API только через SSL.
крипто API. Чтобы клиент мог шифровать контент который уходит на сервер а потом расшифровывать когда он назад приходит. Примерно как у Mega сделано
Вам никто не мешает самостоятельно любым способом шифровать файл и заливать его уже в зашифрованном виде.
.
Владимир. Вы на конференции вчера упомянули про то, что грузить можно не только файлы, но и данные (что-то типа облачной базы). Однако не смог найти про это информацию, а на самой конфе не спросил, так как думал что есть в апи доках.
Не могли бы немного подробнее рассказать?
Не могли бы немного подробнее рассказать?
Это было в рамках рассказа о том, какие задачи мы решаем. Пока эта возможность используется только для наших приложений, но мы обязательно ее апизируем и тогда расскажем.
жду с нетерпением, ибо очень востребовано для меня. (синхронизация конфигов и данных для моих приложений). Правильно ли я понимаю что это какое-то key-val хранилище?
Владимир, вдруг вы общаетесь с командой разработчиков навигатора, передайте им мою просьбу плиз: сделайте уже синхронизацию точек с учёткой в яндексе))) Поменял сегодня прошивку и потерял 200 точек))) В идеале возможность импорта какой нить xml ки и её бекапа в яндекс.диск)))(отправлял им хотелку, наверное года 1.5 назад, говорили что вроде как рассмотрят и тишина)
Владимир, вдруг вы общаетесь с командой разработчиков навигатора, передайте им мою просьбу плиз: сделайте уже синхронизацию точек с учёткой в яндексе))) Поменял сегодня прошивку и потерял 200 точек))) В идеале возможность импорта какой нить xml ки и её бекапа в яндекс.диск)))(отправлял им хотелку, наверное года 1.5 назад, говорили что вроде как рассмотрят и тишина)
Докачка вообще-то есть, но при плохом канале лучше всего использовать приложение Диска, а файлы сохранять себе в Диск. Наше приложение само упорно и не отступая скачает/синхронизирует файлы.
Т.е. докачка есть все же? А каким образом? Вот есть у меня есть ссылка на файл yadi.sk/d/iDuEDZgRAMCvd — и есть у меня на диске первые X байт этого файла, хочу докачать остальные — как я могу это сделать?
Отдайте заголовок
Range: bytes=X-, как и во всех остальных случаях докачки через HTTPЭээ, это я знаю, вопрос куда отдавать то? На какой простите URL-то?
Ну так в конце концов у вас будет временный URL на файл вида downloader-*.disk.yandex.ru/rdisk/blablabla, с которого браузер будет забирать контент. По этому же URL можно и докачивать.
Поясню, т.е. я конечно могу из URL выше сделать запрос вида
Но это выглядит неудобным. Считайте я таким образом просил прямые ссылки на файлы, и наверно, не оригинален.
curl 'https://downloader-default2j.disk.yandex.ru/rdisk/5009ab0a5cfd1f7eb0e254ebb100e1b9/524dc81e/x4HCiStC2DvKAa1kKMcP87B2k28DF4a2wE-o8SkRYFhrBUq3otILRlaqsZGk3cu_q_J6bpmRyOJonT3VoXnDag==?uid=0&filename=random_data.10mb&disposition=attachment&hash=cO/JeeoWUcNRsjzPuSPBhTlB8tvmD9kXUH/MeXT7do8%3D&limit=0&content_type=application%2Foctet-stream&rtoken=f9dfc306a581fcb5ae1c5652885c98bd&rtimestamp=524dc81f' -H 'Accept-Encoding: gzip,deflate,sdch' -H 'Host: downloader-default2j.disk.yandex.ru' -H 'Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Referer: https://disk.yandex.ru/public/?hash=cO/JeeoWUcNRsjzPuSPBhTlB8tvmD9kXUH/MeXT7do8%3D&ncrnd=8469&locale=ru' -H 'Cookie: yandexuid=1022315551361942800; fuid01=4e6f792f0ea2138e.wB1IcGQtAvzEQS8b4VPBAzQxgzHTkhblkoJVlrYrAX8S6FYp9_suY1KPtrTtYPnCD2gmtvAdBjXQP4HRm-eoHihFQw8zx-GO-Dx_jX1HBBn8LBmai7rYeS0K0epLAg0C; yabs-frequency=/4/Im010FvRG5BEc3zH/aTS5BLmL9poT12rS5IURrmWNN1Ky/; my=YzYBAAA=; L=FVlDc0pkAgdxfEVYfl9XZksBdgtHQnRQW1AoChcXKD44CE9ZBnJwLUM3KCAzF1IfLDoAP3Z1UTgQGg5BXUcXMw==.1380825753.9996.272955.01829e03d6124f673e036c164e41ace9; ys=; yp=' -H 'Connection: keep-alive' --compressedНо это выглядит неудобным. Считайте я таким образом просил прямые ссылки на файлы, и наверно, не оригинален.
Я придумал. Извините, что не сразу.
1. Сохраняете файл себе в Диск.
2. Используете любой HTTP-клиент для того, чтобы скачать его себе на компьютер по WebDAV, используя базовую авторизацию. В вебдаве по части GET нет никаких хитростей – достаточно просто корректно урлэнкодить путь, что в случае латинских названий без пробелов – задача тривиальная.
1. Сохраняете файл себе в Диск.
2. Используете любой HTTP-клиент для того, чтобы скачать его себе на компьютер по WebDAV, используя базовую авторизацию. В вебдаве по части GET нет никаких хитростей – достаточно просто корректно урлэнкодить путь, что в случае латинских названий без пробелов – задача тривиальная.
Мгм. Насколько неделикатно будет повторить вопрос — тот самый, который на хабре второй самый задаваемый вопрос по яндекс: диску? Уже год прошёл — кормления завтраками — а воз и ныне там?
Посмотрел на виджет. То ли я не понимаю на кого он рассчитан, то ли юзабилити оставляет желать лучшего.
Одни вопросы…
1. Чем он лучше «обычного» — положил в диск, дал общую ссылку?
2. Зачем отдельная кнопка «сохранить на диск», если можно использовать ссылку (там тоже есть эта кнопка)?
3. Почему при нажатии на «сохранить на диск» я получаю дополнительный запрос (надо еще раз жать кнопку)?
4. Почему при нажатии на «сохранить на диск» в диалоге нет предпросмотра?
5. Если сделать там предпросмотр, то опять же возникает вопрос №2 — чем это отличается от клика по ссылке?
Одни вопросы…
1. Чем он лучше «обычного» — положил в диск, дал общую ссылку?
2. Зачем отдельная кнопка «сохранить на диск», если можно использовать ссылку (там тоже есть эта кнопка)?
3. Почему при нажатии на «сохранить на диск» я получаю дополнительный запрос (надо еще раз жать кнопку)?
4. Почему при нажатии на «сохранить на диск» в диалоге нет предпросмотра?
5. Если сделать там предпросмотр, то опять же возникает вопрос №2 — чем это отличается от клика по ссылке?
И да… в догонку.
Если виджеты и SDK будут расширяться это будет востребовано.
Вот один из юзкейсов: uploadcare.com/
Если виджеты и SDK будут расширяться это будет востребовано.
Вот один из юзкейсов: uploadcare.com/
Спасибо за SDK. Реальное подспорье.
Посмотрел на гитхабе код SDK под C#.
Неймспейсы такого вида:
namespace Disk.SDK { }
Удивился, что в неймспейсах не фигурирует название компании «yandex». По-моему, было бы логичнее, например, так:
namespace YandexDisk.SDK { }
или так:
namespace Yandex.Disk.SDK { }
PS Ни в коем случае не хочу выразить неважение (много отрицаний, но по другому не скажешь) разработчикам SDK (лишь маленький вопросик-придирка). Яндекс, сделали отличный инструмент для нас. Спасибо.
Посмотрел на гитхабе код SDK под C#.
Неймспейсы такого вида:
namespace Disk.SDK { }
Удивился, что в неймспейсах не фигурирует название компании «yandex». По-моему, было бы логичнее, например, так:
namespace YandexDisk.SDK { }
или так:
namespace Yandex.Disk.SDK { }
PS Ни в коем случае не хочу выразить неважение (много отрицаний, но по другому не скажешь) разработчикам SDK (лишь маленький вопросик-придирка). Яндекс, сделали отличный инструмент для нас. Спасибо.
Что то я не понял, а что у них изменилось? Где новый Rest API? Тот же самый WebDav в документации и во всех SDK. Ни какого улучшения в работе с javascript (не удивлюсь если даже CORS прописать нет возможности).
По-моему это какая то шутка… столько ждали а показали редизайн страницы документации и SDK для ленивых.
Буду признателен если меня разубедят, т.к. этого обновления жду давно.
По-моему это какая то шутка… столько ждали а показали редизайн страницы документации и SDK для ленивых.
Буду признателен если меня разубедят, т.к. этого обновления жду давно.
слушайте, я думаю, что вам надо запилить стандарт для доступа к облачным хранилищам. не restful, a restless. метаинфа идёт в отдельной части сериализованная в жсон. файлы идут каждый в своей части. основой взять oauth. вообще следует выработать стандарт для oauth, а то я уже за##4лся использовать различные библиотеки для разных сайтов, хочется универсальной библиотеки для всех однотипных сайтов. разумеется, это не противоречит расширяемости — библиотека должна иметь возможность грузить плагины, реализующие поддержку расширений стандарта.
Спасибо за SDK!
А выложить .Net библиотеки в NUget вы не хотите?
А выложить .Net библиотеки в NUget вы не хотите?
А будет ли кнопка «Сохранить в Яндекс.Диск» по URL без предварительной загрузки файла (как в виджете)? Например, у Dropbox такая кнопка есть. Конечно, можно реализовать «это» и своими силами, используя API, но это на порядок (а то и 2 сложнее). Просто передавать URL, который надо сохранить, намного проще, а следовательно и пользовалось бы большей популярностью.
Самый простой пример — сайт по поиску персонала. HR мог бы сохранять на Диск резюме соискателей в PDF.
Можно ли рассчитывать на появление такой кнопки?
Самый простой пример — сайт по поиску персонала. HR мог бы сохранять на Диск резюме соискателей в PDF.
Можно ли рассчитывать на появление такой кнопки?
1. Очень печальная документация на WebDAV АПИ
Открывая доку на GoogleDrive я вижу примеры работы с их АПИ для 7-ми!!! языков программирования.
А тут только http-заголовки. Какой АПИ выберет разработчик, кажется ответ очевиден.
2. Нет возможности написать Вэб-клиент, т.к. вы НЕ отдаете CORS-заголовки. ПОЧЕМУ?!!! Сколько человеко-лет разработки нужно чтобы отдать в http-заголовке звездочку "*"?
3. Нет поддержки для multipart/fom-data, а именно они используются браузерами при отправке форм (Гугл их кстати поддерживает)
4. У АПИ нет никакого версионирования. Все же это разумно дописывать номер версии в URL,
а у вас просто webdav.yandex.ru. Видимо вы написали «идеальное» АПИ с первой попытки )
5. Большинство методов отдают XML, кроме одного
Это что тяжелое наследие легаси клиентов? Для этого и нужен пункт 4. А как же консистентность АПИ?
Открывая доку на GoogleDrive я вижу примеры работы с их АПИ для 7-ми!!! языков программирования.
А тут только http-заголовки. Какой АПИ выберет разработчик, кажется ответ очевиден.
2. Нет возможности написать Вэб-клиент, т.к. вы НЕ отдаете CORS-заголовки. ПОЧЕМУ?!!! Сколько человеко-лет разработки нужно чтобы отдать в http-заголовке звездочку "*"?
3. Нет поддержки для multipart/fom-data, а именно они используются браузерами при отправке форм (Гугл их кстати поддерживает)
4. У АПИ нет никакого версионирования. Все же это разумно дописывать номер версии в URL,
а у вас просто webdav.yandex.ru. Видимо вы написали «идеальное» АПИ с первой попытки )
5. Большинство методов отдают XML, кроме одного
Это что тяжелое наследие легаси клиентов? Для этого и нужен пункт 4. А как же консистентность АПИ?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SDK от Яндекс.Диска