Ну, есть много способов узнать, как создать веб-приложение RESTful, и нет, единственного правильного способа не существует. RESTful не является стандартом, но использует набор стандартов (HTTP, URI, Mime Type, ...).
Начните с этого: Как я объяснил REST моей жене
Затем перейдите к следующему: RESTful Web Services Cookbook
А затем приложите все усилия для разработки веб-приложений, потому что лучший способ учиться - это проводить эксперименты, и вы можете многому научиться на своих ошибках;)
Не беспокойтесь, если ваши первые веб-приложения не будут полностью RESTful: вы найдете способ сделать это!
Итак, цитируя Оби-Вана Кеноби, «да пребудет с тобой сила!» ;)
РЕДАКТИРОВАТЬ
Хорошо, позвольте мне быть более конкретным.
Вы хотите сделать RESTful веб-приложение, а? Ну, как я уже сказал, есть много способов сделать это, но это главное руководство.
Определение
REST (Transfer State Transfer) - это стиль архитектуры программного обеспечения для распределенной системы (например, WWW). Это не стандарт, но он использует набор стандартов: HTTP, AJAX, HTML, URI, Mime Type и т. Д. Мы говорим о представлении ресурса, а не о самом ресурсе. Взято из «Как я объяснил REST моей жене»:
Жена : веб-страница является ресурсом?
Райан : Вид. Веб-страница является представлением ресурса. Ресурсы - это просто понятия.
Архитектурные ограничения
- Клиент-сервер : клиент и сервер разделены единым интерфейсом (описано ниже).
- Stateless : клиент-сервер связь осуществляется без сохранения определенного состояния клиента на сервере.
- Кэшируемый : клиент может иметь кеш ответов уже выполненных запросов.
- Многоуровневая система : клиент не знает, напрямую ли он связан с конечным сервером или связь осуществляется через промежуточные соединения.
Единый интерфейс
- Идентификация ресурсов : каждый ресурс должен быть идентифицирован по URI.
- Протокол : чтобы получить доступ к клиенту и серверу связи, протокол должен быть сделан раньше. Каждый запрос может иметь правильный MIME-тип (application / xml, text / html, application / rdf + xml и т. Д.), Правильные заголовки и правильный HTTP-метод (см. Описание CRUD ниже).
CRUD
Итак, мы увидели, что для идентификации ресурсов мы можем использовать URI, но нам нужно что-то еще для действий (добавить, изменить, удалить и т. Д.): Отличный прием в CRUD (создание, чтение, обновление и удаление).
- Создать { HTTP: POST } { SQL: INSERT } => создать новый ресурс
- Читать { HTTP: GET } { SQL: SELECT } => получить ресурс
- Обновить { HTTP: PUT } { SQL: UPDATE } => изменить ресурс
- Delete { HTTP: DELETE } { SQL: DELETE } => удалить ресурс
Теперь, что касается PUT и DELETE, могут возникнуть некоторые технические проблемы (вы получите их с помощью HTML-формы): часто разработчики обходят эту проблему, используя POST для каждого запроса «PUT» и «DELETE». Официально вы должны использовать PUT и DELETE. Кстати, делай что хочешь. Мой опыт подталкивает меня к использованию POST и GET каждый раз.
--- Следующая часть должна быть использована, но это не связь REST: это касается связанных данных ---
URI
Абстрактный URI из технических деталей! Попрощайтесь с URI следующим образом:
http://www.example.com/index.php?query=search&id=9823&date=08272012
Перепроектируйте URI! Возьмите ссылку выше и измените ее следующим образом:
http://www.example.com/search/2012/08/27/9823
Это намного лучше, а? Это может быть сделано:
Другое дело: используйте разные URI для представления разных ресурсов:
Обратите внимание : about.html и about.rdf не являются файлами! Они могут быть результатом преобразования XSLT!
Согласование контента
Если вы достигли этой точки, поздравляю! Возможно, вы готовы получить более абстрактные понятия, потому что мы входим в технические детали семантической паутины;) Ну, когда ваш клиент хочет ресурс, он обычно делает следующий запрос:
GET http://www.example.com/about
Accept: application/rdf+xml
Но сервер не будет отвечать about.rdf, потому что у него другой URI ( http://www.example.com/about.rdf ). Итак, давайте посмотрим на шаблон 303 ! Сервер вернет это:
303 See Other
Location: http://www.example.com/about.rdf
И клиент перейдет по ссылке, возвращенной следующим образом:
GET http://www.example.com/about.rdf
Accept: application/rdf+xml
Наконец, сервер вернет запрошенный ресурс:
200 OK
about.rdf
Не волнуйтесь: ваше клиентское приложение ничего с этим не сделает! Шаблон 303 должен быть сделан серверным приложением, а ваш браузер сделает все остальное;)
Вывод
Часто теория далека от практики. Да, теперь вы знаете, как спроектировать и разработать приложение RESTful, но приведенные выше рекомендации являются лишь подсказкой. Вы найдете свой лучший способ создания веб-приложений, и, вероятно, он не будет таким, как того требует теория. Не наплевать: D!
Список используемой литературы
Веб-сервисы RESTful, Самер Тяги
REST API должны быть управляемы гипертекстом, Рой Томас Филдинг
Веб-сервисы RESTful: основы, Алекс Родригес
Webber REST Workflow