Хорошие конечные точки для веб-сервиса RESTful

Question

Я строю простой сервис RESTful и пытаюсь создать хороший дизайн и интуитивно понятные конечные точки. Вот некоторые из идей, которые я придумал после прочтения кучу статей о REST, и хотел получить некоторую обратную связь.

Ресурсы, которые будут подвергаться службой книги -

представление

http://myapp.com/books/?type=fiction&age=15-35&author=american 
http://myapp.com/books/35/chapters/2 
http://myapp.com/books/35/chapters/2/pages/6 
http://myapp.com/books/35/chapters/2/pictures/1 

отклика для каждой конечной точки будет зависеть от способа и Accept заголовка т.е.

GET -H «Accept: приложение/JSON ' 'http://myapp.com/books/35/chapters/2' должно привести к что-то вроде

{ 
    "book": "The Adventures Of Huckleberry Finn", 
    "title": "The Boys Escape Jim", 
    "pages": 15, 
    "pictures": 3 
} 

и тот же запрос с' Accept: APPLI cation/xml 'вернет мне представление xml того же самого.

Пара вещей, которые я не ясно, о:

Поскольку REST диктует, что мы должны использовать существительные, не глаголы, как я разоблачить форму HTML, чтобы ввести новые ресурсы?

/новый или/добавить не РЕСТИТУТ вообще.

бы

GET 'Accept: text/html' 'http://myapp.com/books/new' 

быть приемлемым способом является конечной точкой на странице формы? Или, возможно,

POST 'Accept: text/html' 'http://myapp.com/books/' 

с пустым телом - лучший способ? И тот же POST с пустым телом и

'Accept: application/json' 

закончится ошибкой http 400. Это правильный/разумный подход, или есть лучший способ сделать это?

Я подхожу к этому как к «службе, которая предоставляет ресурсы книг, глав, изображений», а «веб-страница» является лишь одним из представлений этих ресурсов. Итак, технически, если бы я должен был поставить «Accept: text/html» в любом из указанных запросов, я должен ожидать получить html-представление запрашиваемого ресурса. В то же время html - это действительно не данные, описывающие язык, но язык презентации и последующее разделение проблем предполагает сохранение отдельно от представления (html) модели (ресурсов) и контроллера (кода, обрабатывающего запросы).

В целом, должен ли «api», который предоставляет ресурсы, обрабатываться отдельно от пользовательского интерфейса?
Что делать, если это небольшое приложение с одной страницей?

Благодарим за помощь!

Answer 1

Здесь вы задали много вопросов. Я просто добавлю свои 2 цента. API Restful, который вы показываете в начале своего сообщения, выглядит хорошо. Эти «существительные», о которых вы говорили, это имена ваших ресурсов, такие как книги, главы, страницы и т. Д. Идея REST вращается вокруг использования HTTP-глаголов, используемых для взаимодействия с этими ресурсами. Запросы GET будут извлекать эти ресурсы. PUT/POST вставляет или обновляет эти ресурсы, а DELETE удаляет ресурсы.

Других слова:

GET http://myapp.com/books/35

получит книгу с идентификатором 35, но

POST http://myapp.com/books/

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

Надеюсь, что это поможет ...