Как стать автором
Обновить

Комментарии 58

Пожелание №1: Сделайте демо-доступ к API — чтобы какие-то функции можно быть запускать без авторизации. Это очень полезно для отладки, когда только начианаешь разрабатывать приложение. Если все данные нельзя отдавать без авторизации, то сделайте простенькую функцию, которая будет отдавать точное время — оно-то уж точно не секрет и меняется при каждом вызове :)
Делаю, возможно скоро будет, ибо сейчас для разработки внутренних приложений, нужно «Создать» приложение, получить ключ и т.д, что не очень удобно.
НЛО прилетело и опубликовало эту надпись здесь
Я думаю, что смысл в том, что в некоторый момент помышленными стандартами дефакто становятся решения от «монстров индустрии». В данном случае это Facebook. Может, и Вконтакте и мылу.ру придется присмотреться к REST. Это как я понял позицию автора…
НЛО прилетело и опубликовало эту надпись здесь
Рискую быть заминусованным, но все же спрошу: А разве в том же вконтакте не REST? Ведь там так же через GET/POST посылается запрос к апи, и также ответ получается в виде XML или JSON.

Единственное, входные данные (название метода и параметры) также упаковываются в XML, как и выходные… — это единственное, что отличает данный подход от REST?
НЛО прилетело и опубликовало эту надпись здесь
Вы наверное плохо знаете, что представляет из себя этот апи, а я вот реализовывал его для нашего проекта, как zend_service, и поэтому могу сказать такие вот вещи — это не REST иначе вместо GET или POST (как собственно вам удобно — они равнозначны) запроса по адресу api.vkontakte.ru/api.php (уже глядя на эту строчку можно понять что это явно не наша любимая архитектура) с кучей параметров, для, к примеру взятия баланса приложения мы бы пользовались чем-то подобным api.vkontakte.ru/applications/{идентификатор приложения}…

хотим снять бабло с пользователя… и начинаем понимать что rest тут не очень уместен ;)
буду занудой:

scribbler.ru/developers/details/user:
user.denieFriendShip — Запретить дружбу.


user.denyFriendShip было бы правильней. Не суть конечно, просто режет глаз.
Если занудствовать, то user.denyFriendship еще правильнее :-)
буду занудой и исправлю ;)
НЛО прилетело и опубликовало эту надпись здесь
Вы меня извините, но в этом потоке сознания сложно разобраться.
REST — это не протокол, а подход. На его основе сделано почти все. Но это слишком общая вещь. Я бы рекомендовал использовать SOAP. Вот как разобраться в вашем примере? Он какой-то слишком наколечноый? Где описание XML Schema или хотя бы DTD? Как с этим работаь? Как вам отправлять запрос, как его парсить/понимать?

НЛО прилетело и опубликовало эту надпись здесь
Можно.
Мое лично мнение, что XMLRPC лучше для быстрого старта, он менее формализован, поэтому хорош, когда надо что-то быстро передать.
Для серьезной работы лучше использовать SOAP — он сложнее, формализованнее, строже, и с ним сложнее разобраться. Но потом это все окупатеся.
каким образом окупается SOAP?
Для работы с SOAP нужно иметь свои классы на стороне клиента, что не очень приятно и удобно.
А чем это плохо?
Довольно приятно и удобно. Сейчас напишу подробнее.
НЛО прилетело и опубликовало эту надпись здесь
Здесь описан принцип работы, REST не протокол, а идеология я бы сказал.
НЛО прилетело и опубликовало эту надпись здесь
Верно. Но если говорить про API — то оно не может быть абстрактным в отличие от идеологии.
Но на одной идеологии работать не будешь. Работать может только ее реализация.
АПИ — это конкретная реализация — в функцию getUserInfo отправил параметр userId с номерjv пользователя, в ответ получил объект типа UserInfo с полем regDate в формате RFC822 с датой регистрации этого пользователя.

Но все равно мне нравится такой вариант использования реста.
вообще-то ещё один из хороших принципов REST состоит в том, чтобы не дублировать в запросе методы. Когда вы хотите что-то получить, вы используете HTTP-метод GET, и нет смысла писать в урле /user/getInfo, достаточно просто /user/info. Когда вы хотите что-то добавить, вы используете HTTP-метод PUT на урл /comments, удалить — метод DELETE на тот же урл. Большинство глаголов в урлах становятся не нужны.

короче:
GET /user/info — прочитать информацию
POST /user/info — обновить информацию

GET /item/comments — получить комментарии
PUT /item/comments — добавить комментарий
DELETE /item/comments — удалить комментарий

и так далее
Реализовать можно по разному, просто я посчитал, что так будет нагляднее, что типо синтаксиса обращения к методу объекта.
почитайте книжку RESTful web applications. там как раз описано какая разница между RPC-style API и REST.

И она как раз и заключается в переходе от вызова процедур к управлению ресурсами:
были вызовы getUser(), createUser(),…
стало
применение HTTP глаголов к ресурсу user. Стандартный CRUD при помощи HTTP методов.
В любой статье о REST об этом говорится
Create — POST
Read — GET
Update — PUT
Delete — DELETE
Похоже автор просто не понял что такое REST
REST-подход вместе с MVC вообще штука хорошая, а если он был применен в движке сайта — то api на это дело тоже удобно навесить restful, тупо добавив распознавание типа входящего запроса — вся логика остается той же.
Это дело очень принято в рельсах (ruby on rails) и всем на них основанном и выглядит примерно так:

def update
  @resource = Resource.find(params[:id])
  @resource.update_attributes!(params)
  respond_to {|wants|
    wants.html { }
    wants.json { render :json => @resource }
    wants.xml { render :xml => @resource.to_xml }
  }
end
Также это дело присутствует и в Zend framework, а рельсы определенно — всегда радуют.
Возможно для js разработчиков было бы неплохо отдавать feed в формате json, а для php (php4) хорошо было бы в форме сериализированного массива. В json форме многие отдают.
Верно подмечено и это стоит в планах, xml был выбран в качестве основного формата отдаваемых данных, т.к. его можно везде распарсить, а в будущем желаемый формат можно будет указывать, как входной параметр, в данный момент API, так сказать в стадии тестирования.
Вы, вероятно, в описании API западных сайтов дочитали только до слова REST и тут же кинулись его имплементировать.

Советую прочитать чуть дальше и дойти хотя бы до OAuth — чтобы пользователю не приходилось сообщать свой пароль любой левой тулзовине и чтобы оные пароли не гнались незащищёнными по basic authorization.
Читайте статью до конца, пожалуйста.

В следующий раз продолжим беседу об OAuth авторизации, которая позволяет не вводить логин и пароль пользователя, для использования API.
Я зашёл на scribbler.ru/developers/auth и увидел basic auth без вариантов. Беседа — это хорошо, но речь-то о реализации.
Да, правильно, потому, что еще не дошел до реализации OAuth.
И поздравляю вас, вы снова изобрели велосипед. Видимо потому, что так и не поняли что такое rest, и как вобще с помощью этой архитекруты что либо делать.

Какая привязка к объекту то? Забудьте об объектах, в rest существуют так называемые коллекции (collections) и собственно члены этих коллекций (member) + банальный HTTP-шный CRUD (собстна те самые PUT, GET, POST и DELETE) для работы с ними.

Если вы до сих пор не видете разницу между RESTful API и вашим, объясню на примере (/api/user.getInfo?userId=10);

GET /users/ — получаем всех юзеров
GET /users/10 — получаем пользователя с URI (илиже индентификатором) — 10

ну и:
DELETE /users/ — убиваем всех пользователей

Всё это хорошо, но как я понял из рассылки вконтакт специально сделал свой АПИ таким и всячески приветствует отказыватся от других сервисов.
Venor lock-in за исключением возможно Яндекса в рунєте процветает.
Ох уж эти PHP программисты, вечно все исковеркают.
Автор, пожалуйста, почитайте внимательнее про REST или хотя бы комментарии к этой статьи.
Ок, надо написать API использует принципы идиологии REST? Чтобы всем было хорошо ;)
НЛО прилетело и опубликовало эту надпись здесь
Тогда twitter тоже противоречит, и facebook с ним на пару?

twitter:
«The Twitter API attempts to conform to the design principles of Representational State Transfer (REST)»

facebook:
«The API uses a REST-like interface»

wiki.developers.facebook.com/index.php/API
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется что REST-like — это просто HTTP + URL + отсутсвие состояния. Собственно, можно сказать, что у нас большая часть всего в сети так или иначе REST-like
НЛО прилетело и опубликовало эту надпись здесь
Проще говоря, каждый называет REST'ом, то, что хочет назвать REST'ом.
Спасибо, вносите ясности в дискуссию.
НЛО прилетело и опубликовало эту надпись здесь
Прочитал, понял, доходчиво. плюс.
НЛО прилетело и опубликовало эту надпись здесь
> .../api/user.getInfo?userId=10

Как-то это совсем не похоже на REST. Правильно было бы /api/users/10.xml
А зачем .xml?
/api/users/10 выглядит красивее и «рестовее».
У пользователя может быть желание получить информацию в JSON, XML, CSV, еще каком-то из форматов. Он может указать желаемый формат заголовками, конечно, но неплохо бы иметь возможность выбора и в URL-е.
Рест вроде как предполагает Content-Negotiation.
А все равно /api/users/10/xml выглядит рестовее :)
По URI идее 10.xml, 10.json, 10.html обозначают разные сущности с разными именами, а 10/xml, 10/html и 10/json — разные подсущности (или же интерфейсы) одной сущности. Их действительно удобно использовать для явного обращения к конкретному интерфейсу объекта, в то время как просто 10 — общий вид на основе автоматических правил выбора.
Боюсь что не рестовее. Рестовее было бы /api/users/10/presentations/xml, если уж думать так, как вы думаете. Но это тоже не совсем правильно, ибо формат представления не является каким-либо ресурсом. Его нельзя удалить, добавить, изменить извне. Он есть в самой системе. Система может уметь или не уметь представлять объект в каком-либо формате. И именно расширение (.xml, .json) является самым правильным вариантом.
А как scribbler привлекает и стимулирует сторонних разработчиков?
В скором будущем будут задействованы внутренняя валюта — кредиты, а также было бы интересным узнать, что нужно разработчикам, для их «стимуляции»?
Ну разработчики должны быть заинтересованы в том, чтобы писать приложения для scribbler.

У Вас же api отличается от вконтактовского, а Дуров запретил размещать приложения вконтакте в других социальных сетях, аргументировав это желанием заставить всех использовать единое api.
Это значит, что авторы приложений вконтакте просто так не пойдут на scribbler.

Вконтакте имеет следующие преимущества:
1. огромная аудитория
2. готовая система монетизации
3. удобные возможности раскрутки
4. конкурсы для разработчиков
Доход от приложения вконтакте может приносить огромные деньги.

Scribbler должен предложить какую-то альтернативу — почему разработчики будут писать для scribblerа вместо вконтакта?
Задание для маркетологов, пойду нагружу и попозже отвечу.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.