Верно ли, что для реализации RESTful API необходимо реализовать структуру URL, которая выглядит так:
http://example.com/post/
http://example.com/post/123
где /123 будет использоваться для редактирования, удалите
Еще один способ задать вопрос: может ли URL, который выглядит так, называется RESTful?
http://example.com/script.php?method=get_title&blogid=123
Вам не нужно создавать структуру URI. Это также может быть /some_obscure_string/base64_encoded_title/unique_id. Это также может быть RESTful, в зависимости от нескольких других факторов.
Но есть несколько лучших практик в том, как создавать URI в веб-приложении RESTful и быть такими же простыми и как можно более читаемыми для человека, является одним из них.
Ваш пример http://example.com/script.php?method=get_title&blogid=123 также может быть RESTful, но параметры запроса указывают на то, что вместо него используется какой-то RPC- или RMI-over-HTTP.
Подводя итог: не задумывайтесь над своим дизайном URI. Это будет автоматически с хорошим и правильным дизайном RESTful вашего приложения.
Идея REST заключается в том, что каждый ресурс имеет свой собственный URL-адрес, и вы используете различные методы HTTP для взаимодействия с этими ресурсами. Имеет смысл определить структуру URL-адресов, чтобы иерархия между различными ресурсами отражалась в URL-адресе, но вам не нужно.
Если у вас есть такие URL-адреса,
/all-posts/
/first-post
/some-stuff/second-post
/third-post
вы все равно можете предоставить API RESTful. Идея заключается в том, что от GET до /all-posts/ возвращает список URL-адресов каждого почтового объекта, и клиент использует эти URL для взаимодействия с ресурсами. В основном URL-адреса должны обрабатываться клиентом непрозрачными данными.
Пока URL-адрес, встроенный в клиент, не изменится, вы также можете изменить структуру без необходимости изменения клиента.
URL вашего примера, вероятно, не принадлежит API RESTful, так как он содержит метод get_title. В REST URL-адрес представляет собой вещь. Что делать с вещью (если она будет изменена, если содержимое будет извлечено,...) не является частью URL-адреса, поскольку REST использует различные методы HTTP.
Ключевым аспектом REST является то, что URL-адрес является ресурсом. ури вроде
http://example.com/script.php?etc-etc-etc
не помещает идентификатор ресурса в ресурсную часть uri. что не сказать, что API RESTful никогда не должен использовать параметры get; на самом деле, это просто отлично:
http://example.com/posts?sort=date_asc&offset=20&limit=10
может быть отличным способом получить URI третьей страницы самых старых сообщений. Однако использование параметров get таким образом должно использоваться только в запросах, где метод также GET. PUT и особенно методы POST должны действительно использовать простой uri с ресурсом, который будет затронут только в части пути.
RESTful URI-дизайн - это все о доступе к ресурсам, и они должны быть структурированы в стиле RESTful, поэтому вы не должны иметь никаких строк запроса.
например. GET
авторы/
авторы/1
авторы/1/книги
авторы/1/книги/10
авторы/1/книги/10/Резюме
и др.
В наши дни все что угодно и все называется RESTfull, просто посмотрите на некоторые ответы его изобретателя доктора Роя Филдинга, и вы получите некоторые идеи. Стоит сделать некоторые чтения по этому вопросу.
P.S вам не нужна почта, получить и т.д. в ваших URI, HTTP-протокол в настоящее время в основном используется для использования API REST, и вы можете передать глагол как часть вызова. Также существует концепция согласования контента, то есть вы можете запросить любой доступный формат из REST API (json, xml atc).
Примеры URL-адресов:
GET http://del.icio.us/api/
GET http://del.icio.us/api/peej/tags/
GET http://del.icio.us/api/peej/tags/test
DELETE http://del.icio.us/api/peej/bookmarks/[hash]
Концепция REST действительно основана на том, что она управляется URL-адресами и не управляется большими блоками данных. С помощью REST вам не нужно передавать гигантский запрос на мыло, чтобы вызвать метод - ваш метод вызова/создания объекта/все, что вы хотите сделать, вызывается просто URL-адресом и глаголом, который вы использовали против этого URL-адреса.
Структура ваших URL-адресов не имеет значения. Важно то, что каждый URL-адрес идентифицирует ровно 1 ресурс. Каждый ресурс может иметь несколько URL-адресов, указывающих на него, но каждый URL должен указывать только на один ресурс.