Важные аспекты RESTful API для вашего проекта

[LIAL]

Кратко. Ёмко. Ясно. Спасибо, что хоть кто-то разложил по полочкам более-менее.

[shaelf]

Мне кажется, это самая правильная расшифровка :)

[zerkms]

Авторская версия, тем не менее, звучала как «Keep it simple and stupid», что придавало несколько другую окраску.

[tsmar]

PUT и DELETE достаточно просто реализуются “по-человечески” средствами AJAX на стороне клиента-браузера, не стоит пугать новичков (во всяком случае во всех актуальных браузерах). К тому же у многих популярных фреймворков есть соответствующие методы.

[FSB]

Зато если захотите помимо AJAX клиента подключиться клиентов на другой технологии (например Flash) то столкнетесь с этими граблями — на родном API флеш не умеет слать PUT/DELETE HTTP запросы и задача обычно решается как раз указанной в статье перегрузкой POST запроса. Так что лучше поддержать фичу на сервере заранее, чем прикручивать потом )

[matriks]

Опередили :)
добавлю к этому еще, что необходимо чтобы еще и веб-сервер (Apache, lighttpd, или что там стоит) поддерживал соответствующий метод
попробуйте хостера убедить открыть эти методы, да и на своих серверах открывать нужно о-о-очень аккуратно и грамотно, дабы не сделать дырку в безопасности сервака ;)

[LexL]

Browser Plugin API предоставляет только GET/POST, поэтому Flash как бы ни хотел, но PUT/DELETE не сможет…
Если только собственный HTTP stack задейтсвует. Но в этом случае, прощайте браузерные куки.

[Kobs]

Хоть REST используют в основном когда пишут на ява, но вот неплохая статья для пхпистов
www.lornajane.net/posts/2008/Accessing-Incoming-PUT-Data-from-PHP
И firefox RESTClient addons.mozilla.org/en-US/firefox/addon/9780/ лично мне очень помогал в разработке.

[matriks]

«Хоть REST используют в основном когда пишут на ява, но вот неплохая статья для пхпистов» — пруфлинт на статистику в студию
по мне — смутное утверждение

[Alroniks]

есть мысль, что репозиторий пакетов для CMS MODx пишется как раз таки с соблюдений REST-архитектуры. Документации пока нету подробной, но то, что мне удалось раскопать, указывает на этот факт. Это к теме PHP и иже с ним.

[matriks]

Подобный экстеншн для хром — chrome.google.com/extensions/detail/fhjcajmcbmldlhcimfajhfbgofnpcjmb

[anycolor]

>Хоть REST используют в основном когда пишут на ява,

Полный бред. Технология эта не привязана к какому-то конкретному языку. И нет никакой проблемы сделать тоже самое на PHP, Ruby, .NET или еще где.

[kirsan_vlz]

Да рельсы вообще практически «искаропки» работают с REST. Там даже скаффолдер маршруты и контролеры создаёт REST-ориентированные.

[VolCh]

аналогично symfony, кодогенератор и автоматический роутинг для CRUD «REST-совместимый»

А вообще 99% совместимости урлов с REST для нормально спроектированного приложения, имхо, можно решить с помощью mod_rewrite и аналогов в других серверах. Сложнее с HTTP-методами

[FractalizeR]

(эй-пи-ай, а не “апи”, как многие привыкли произносить)

дропбокс делает запрос к веб-сервису гугля

«гугла», а не «гугля», как многие привыкли произносить…

[Amka]

Тогда уж «гугл» :)

[matriks]

соглашусь с вариантом «гугл», но «гугла» ничем не отличается от «гугля» — в англ нет склонений окончаний :)

[heel]

Я тоже не понял, почему автора так затронуло слово «апи», когда в статье полно слов типа «гугля», «апликуха» и т.д.

[BreathLess]

Я уж молчу про «раутер».

[fralik]

Спасибо за информацию. Все–таки отмечу употребление терминов. Можно сделать текст гораздо более удобным для чтения, «раутер» — путь, «эй–пи–ай» — программный интерфейс или интерфейс, «мессажд» — сообщение. Если вы пишите «эй–пи–ай», то почему дальше по тексту HTTP, CRUD и другие, вместо аш–ти–ти–пи, си–эр–у–д?! А кое–где встречается API, а сразу за ним эй–пи–ай… Это небольшие замечания к оформлению, а не к сути, но из–за них хотелось поскорее прокрутить текст вниз, посмотреть список литературы и отправиться читать про сервисы в другом изложении.

[matriks]

спасибо за конструктивный комментарий, есть такой грешок — разбавлял статью, чтобы не была унылой, возможно выбрал неудачный способ, но после боя руками не машут

[huze]

Всё вы сделали правильно.

[ItGold]

это произносится как «эйч-ти-ти-пи» и «крад» соответственно.

[asm0dey]

си-ар-ю-ди

[AlexanderYastrebov]

Сам спрошу и сам отвечу:
В: Для определения типа ответа, заголовок Accept является более идеологически верным способом чем «расширение», так?
О: Так, но возможно что не все клиенты будут полноценными (см POST vs PUT), т.е. не смогут передать нужный заголовок. Плюс теряется возможность отладки на скорую руку с помощью браузера.

[matriks]

все верно, есть еще уйма плюшек и заголовки в RESTful сервисах — это отдельная тема, в статье освешены только базовые аспекты

[AlexanderYastrebov]

Думаю стоит также отметить еще один из основных идеологических принципов: URL — ресурс, объект. Метод — действие.
Примеры (верно != неверно):
POST /user != POST /user/add
GET /user/123 != GET /user/list/123
PUT /user/123 != PUT /user/edit/123
DELETE /user/123 != DELETE /user/delete/123

[igrishaev]

Спасибо.
Добавлю про метод HEAD, который, по идее, нужен для получения краткой информации об объекте.
Например, в REST-API для Amazon S3 HEAD используется, чтобы получить метаинформацию о файле, не скачивая его целиком.

[VolCh]

Для быстрого старта в свое время мне помогла страничка microformats.org/wiki/rest вообще и microformats.org/wiki/rest/urls в частности

[WildWolf]

приведенная вами статья для примера — не REST.

[matriks]

громкое заявление, но лишенное смысла
просветите присутствующих?

[WildWolf]

Я описал построение элементарного API, реализуемого минимумом кода.
Я не говорю, что вы не правы или REST это плохо. Но некоторые его особенности плохо вкладываются в предметную область — собственно выше это уже отметили. И самая его вкусная часть — PUT/DELETE не реализуема из флеша сотоварищи.
Велосипедная авторизация у меня тоже была диктована предметной областью — мой пример вырван из SaaS системы. Естественно он является вырожденным и совсем не общим.
Предлагаю не начинать войны — мы оба правы.

[LexL]

Дальнейшее логическое развитие этого API — odata.org

[WildWolf]

да, что-то вроде этого и есть.

[VolCh]

Может во мне бурлят «пережитки прошлого», но когда я слышу/вижу рядом «формат» и «Microsoft», то заранее содрогаюсь

[LexL]

У меня, возможно, бурлят пережитки настоящего, содрогаюсь, когда вижу «Google». Но это не мешает мне пользоваться их поиском, картами и ютюбиком :)

[VolCh]

Гугл не потребует от вас прекратить использовать поиск и карты и заплатить за «недополученную прибыль», а вот от MS подобные прецеденты были за использование их форматов.

[LexL]

AtomPub/Rss/Odata — это открытые форматы.

ЗЫ. Кроме того, МС блох никогда не ловил. Только крупных конкурентов.

[MagaSoft]

«раутер» — рунглиш тут по круче суржика будет.
про POST с PUT — ложь и провокация.
и хватит уже википедию переносить. напишите на худой конец о своей реализации, получите и PR и конструктивную критику. а так…

[tenshi]

> REST — это “Representational State Transfer”, другими словами — представление данных в удобном для клиента формате

это настолько «другие» слова, что они окончательно потеряли связь с действительностью.

[resurection]

Сравнил написанное здесь, с тем что было написано в предыдущей «неуклюжей» статье, которая указана в первом абзаце. И, честно, я не нашёл сильно принципиальных отличий. Может быть только одно.

1. Использование GET/POST/PUT/DELETE — уже написали выше, что это не подходит. Придётся использовать 'http_method' (в предыдущей статье это 'cmd').

2. Использовать URI (/api/mc/v1/) вместо GET-параметров — единственное принципиальное отличие. Хотя (по моему) это не KISS (ИМХО). Потому что надо дополнительно делать rewrite_rule + парсить строку. А вот так не надо ничего лишнего: '/api?cmd=mc.v1.prefs.mydevelopersuid' — это ближе к KISS.
Ну и команда «mc» — совсем не юзабельно. Без документации не разберёшься. Надо переименовать в messageCenter.

3. OAuth я использовать вообще не могу, потому что пишу сервер для full-flash сайта на котором юзеры могут регистрироваться и авторизовываться как на html-сайте через формы.

4. > error responding клиенту на уровне HTTP статуса. «200 OK».
Видимо, это относится только к внутренним ошибкам скрипта. Например, при регистрации юзера, я могу вывалить сразу список ошибок: 150 и 170 — логин занят и мыло занято. То есть ошибки придётся отдавать в теле. И это тоже из предыдущей статьи.

Не спорю, что статья хорошая и есть над чем подумать. Я уже запланировал несколько правок в своё эй-пи-ай. Но предыдущего оратора Вы зря обидели.

[matriks]

1. http_method нужно использовать только для перегрузки указанных методов, а не постоянно, соответственно сравните GET /api/mc/v1/prefs/mydevelopersuid.json и GET /api?cmd=mc.v1.prefs.mydevelopersuid&data=json&version=v1…
2. я привел ссылки на книги, группы, вики, Вы можете погуглить и поинтересоваться на эту тему — споров много, но то как я указал — это хорошие манеры в REST
3. «на котором юзеры могут регистрироваться и авторизовываться как на html-сайте через формы» — не понял каким боком это здесь, чем это OAuth при этом мешает? ну вводите данные с html-формы, в чем затык?
4. что такое 150, 170 — что за коды? да rfc 2616 не запрещает 1хх, но явно указывает на его лимитирование: не использовать для http/1.0, если 150 и 170 — это Ваши статус коды, то Вы заведомо себя ограничили, как ни крути, а http/1.0 еще много где используется. В данном случае я бы возвращал «409 Conflict», который на мой взгляд больше подходит к ситуации: «The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request.»

P.S. если речь идет о REST, давайте говорить о нем, в статье описаны базовые принципы и общепринятые практики, отработанные в компаниях с мировыми именами и разработанные при участии известных личностей. Если у Вас есть весомые аргументы, добро пожаловать в группу на яху, там всегда готовы к конструктивному диалогу.

[resurection]

1. Я правильно понимаю, что Вы предлагаете реализовать оба варианта и в документации к API написать: «есть два варианта: ....»?

3. > в чем затык?
Да он мне на фиг не нужен. Мой сайт не предоставляет API для третих сервисов.

4. Представьте, юзер заполнил регистрационную форму во flash. Flash POST-ом отправил на сервер дюжину полей. В процессе валидации я обнаружил 3 ошибки (логин занят, е-майл занят, пароль слишком короткий). Если я верну «409 Conflict», то как flash поймёт сколько и какие ошибки? Никак. По этому, я изобретаю и в документации описываю свои коды ошибок и говорю, что в ответе их может быть несколько. Например:

{
errors:{ 150, 170, 250 }
}

так клиентский флеш понимает и показывает юзеру сразу несколько сообщений об ошибках.

Статья хорошая. Но мы с Вами смотрим с разных сторон. Я через свою призму flash-сайтов. А Вы через призму межсервисной интеграции. Отсюда разная специфика.

[AlexanderYastrebov]

Просто не надо пытаться все ошибки разрулить средствами HTTP. Оставьте ему ошибки общего характера (403, 404, 405, 406, 500 и т.д.), а прикладные ошибки возвращайте своими кодами и описаниями с HTTP кодом 200

[poltora]

Table 1: Relationships Between SQL and HTTP Verbs

Action SQL HTTP
Create Insert PUT
Read Select GET
Update Update POST
Delete Delete DELET

www.oracle.com/technetwork/articles/javase/index-137171.html