Комментарии 58
Пожелание №1: Сделайте демо-доступ к API — чтобы какие-то функции можно быть запускать без авторизации. Это очень полезно для отладки, когда только начианаешь разрабатывать приложение. Если все данные нельзя отдавать без авторизации, то сделайте простенькую функцию, которая будет отдавать точное время — оно-то уж точно не секрет и меняется при каждом вызове :)
НЛО прилетело и опубликовало эту надпись здесь
Я думаю, что смысл в том, что в некоторый момент помышленными стандартами дефакто становятся решения от «монстров индустрии». В данном случае это Facebook. Может, и Вконтакте и мылу.ру придется присмотреться к REST. Это как я понял позицию автора…
НЛО прилетело и опубликовало эту надпись здесь
Рискую быть заминусованным, но все же спрошу: А разве в том же вконтакте не REST? Ведь там так же через GET/POST посылается запрос к апи, и также ответ получается в виде XML или JSON.
Единственное, входные данные (название метода и параметры) также упаковываются в XML, как и выходные… — это единственное, что отличает данный подход от REST?
Единственное, входные данные (название метода и параметры) также упаковываются в XML, как и выходные… — это единственное, что отличает данный подход от REST?
НЛО прилетело и опубликовало эту надпись здесь
Вы наверное плохо знаете, что представляет из себя этот апи, а я вот реализовывал его для нашего проекта, как zend_service, и поэтому могу сказать такие вот вещи — это не REST иначе вместо GET или POST (как собственно вам удобно — они равнозначны) запроса по адресу api.vkontakte.ru/api.php (уже глядя на эту строчку можно понять что это явно не наша любимая архитектура) с кучей параметров, для, к примеру взятия баланса приложения мы бы пользовались чем-то подобным api.vkontakte.ru/applications/{идентификатор приложения}…
хотим снять бабло с пользователя… и начинаем понимать что rest тут не очень уместен ;)
хотим снять бабло с пользователя… и начинаем понимать что rest тут не очень уместен ;)
буду занудой:
scribbler.ru/developers/details/user:
user.denyFriendShip было бы правильней. Не суть конечно, просто режет глаз.
scribbler.ru/developers/details/user:
user.denieFriendShip — Запретить дружбу.
user.denyFriendShip было бы правильней. Не суть конечно, просто режет глаз.
НЛО прилетело и опубликовало эту надпись здесь
Вы меня извините, но в этом потоке сознания сложно разобраться.
REST — это не протокол, а подход. На его основе сделано почти все. Но это слишком общая вещь. Я бы рекомендовал использовать SOAP. Вот как разобраться в вашем примере? Он какой-то слишком наколечноый? Где описание XML Schema или хотя бы DTD? Как с этим работаь? Как вам отправлять запрос, как его парсить/понимать?
REST — это не протокол, а подход. На его основе сделано почти все. Но это слишком общая вещь. Я бы рекомендовал использовать SOAP. Вот как разобраться в вашем примере? Он какой-то слишком наколечноый? Где описание XML Schema или хотя бы DTD? Как с этим работаь? Как вам отправлять запрос, как его парсить/понимать?
НЛО прилетело и опубликовало эту надпись здесь
Можно.
Мое лично мнение, что XMLRPC лучше для быстрого старта, он менее формализован, поэтому хорош, когда надо что-то быстро передать.
Для серьезной работы лучше использовать SOAP — он сложнее, формализованнее, строже, и с ним сложнее разобраться. Но потом это все окупатеся.
Мое лично мнение, что XMLRPC лучше для быстрого старта, он менее формализован, поэтому хорош, когда надо что-то быстро передать.
Для серьезной работы лучше использовать SOAP — он сложнее, формализованнее, строже, и с ним сложнее разобраться. Но потом это все окупатеся.
Для работы с SOAP нужно иметь свои классы на стороне клиента, что не очень приятно и удобно.
Здесь описан принцип работы, REST не протокол, а идеология я бы сказал.
НЛО прилетело и опубликовало эту надпись здесь
Верно. Но если говорить про API — то оно не может быть абстрактным в отличие от идеологии.
Но на одной идеологии работать не будешь. Работать может только ее реализация.
АПИ — это конкретная реализация — в функцию getUserInfo отправил параметр userId с номерjv пользователя, в ответ получил объект типа UserInfo с полем regDate в формате RFC822 с датой регистрации этого пользователя.
Но все равно мне нравится такой вариант использования реста.
Но на одной идеологии работать не будешь. Работать может только ее реализация.
АПИ — это конкретная реализация — в функцию 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 — удалить комментарий
и так далее
короче:
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
И она как раз и заключается в переходе от вызова процедур к управлению ресурсами:
были вызовы getUser(), createUser(),…
стало
применение HTTP глаголов к ресурсу user. Стандартный CRUD при помощи HTTP методов.
В любой статье о REST об этом говорится
Create — POST
Read — GET
Update — PUT
Delete — DELETE
Похоже автор просто не понял что такое REST
Хорошо еще опираться на такие статистики:
www.programmableweb.com/apis
www.programmableweb.com/apis
REST-подход вместе с MVC вообще штука хорошая, а если он был применен в движке сайта — то api на это дело тоже удобно навесить restful, тупо добавив распознавание типа входящего запроса — вся логика остается той же.
Это дело очень принято в рельсах (ruby on rails) и всем на них основанном и выглядит примерно так:
Это дело очень принято в рельсах (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
Возможно для js разработчиков было бы неплохо отдавать feed в формате json, а для php (php4) хорошо было бы в форме сериализированного массива. В json форме многие отдают.
Вы, вероятно, в описании API западных сайтов дочитали только до слова REST и тут же кинулись его имплементировать.
Советую прочитать чуть дальше и дойти хотя бы до OAuth — чтобы пользователю не приходилось сообщать свой пароль любой левой тулзовине и чтобы оные пароли не гнались незащищёнными по basic authorization.
Советую прочитать чуть дальше и дойти хотя бы до OAuth — чтобы пользователю не приходилось сообщать свой пароль любой левой тулзовине и чтобы оные пароли не гнались незащищёнными по basic authorization.
Читайте статью до конца, пожалуйста.
В следующий раз продолжим беседу об OAuth авторизации, которая позволяет не вводить логин и пароль пользователя, для использования API.
В следующий раз продолжим беседу об OAuth авторизации, которая позволяет не вводить логин и пароль пользователя, для использования API.
Я зашёл на scribbler.ru/developers/auth и увидел basic auth без вариантов. Беседа — это хорошо, но речь-то о реализации.
И поздравляю вас, вы снова изобрели велосипед. Видимо потому, что так и не поняли что такое 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/ — убиваем всех пользователей
Какая привязка к объекту то? Забудьте об объектах, в 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 за исключением возможно Яндекса в рунєте процветает.
Venor lock-in за исключением возможно Яндекса в рунєте процветает.
Ох уж эти PHP программисты, вечно все исковеркают.
Автор, пожалуйста, почитайте внимательнее про REST или хотя бы комментарии к этой статьи.
Автор, пожалуйста, почитайте внимательнее про 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
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
> .../api/user.getInfo?userId=10
Как-то это совсем не похоже на REST. Правильно было бы /api/users/10.xml
Как-то это совсем не похоже на REST. Правильно было бы /api/users/10.xml
А зачем .xml?
/api/users/10 выглядит красивее и «рестовее».
/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/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а вместо вконтакта?
У Вас же api отличается от вконтактовского, а Дуров запретил размещать приложения вконтакте в других социальных сетях, аргументировав это желанием заставить всех использовать единое api.
Это значит, что авторы приложений вконтакте просто так не пойдут на scribbler.
Вконтакте имеет следующие преимущества:
1. огромная аудитория
2. готовая система монетизации
3. удобные возможности раскрутки
4. конкурсы для разработчиков
Доход от приложения вконтакте может приносить огромные деньги.
Scribbler должен предложить какую-то альтернативу — почему разработчики будут писать для scribblerа вместо вконтакта?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
API для сайта, хватит изобретать велосипед!