Как лучше сделать архитектуру REST API, которое берет один и тот же контент из БД MySQL, а клиенту возвращает в разных форматах: JSON, XML и HTML?

Question

[VZVZ]

Сейчас есть 1 скрипт:
images.get.json.php
по адресу root/api/images.get

Планируется иметь 3 скрипта:
images.get.json.php
по адресу root/api/images.get
images.get.xml.php
по адресу root/api/images.get.xml
images.get.html.php
по адресу root/api/images.get.html

("Возвращать ответы в виде HTML" звучит странно, но если приглядеться к какому-нибудь VK или Facebook, то у них тоже так же, только у них это не относится к API и отличается от него до неузнаваемости. А я это хочу не только для облегчения AJAX, но и для использования в системах наподобие Cordova/Sciter/NW.js и прочем, где UI строится на HTML+CSS(+JS))

Подсознание говорит: ну не делай ты 3 отдельных скрипта, делай 1 общий, с параметром (json | xml | html), а там пусть if ... else if ... else разбирается, ну а URLу надлежащий вид придашь через htaccess...

Но увы.
htaccess терпеть не могу, регулярки терпеть не могу, это натуральный Brainfuck, слишком громоздкие скрипты тоже не люблю, короче, хочу отдельными файлами и точка.

А раз отдельными, то надо, очевидно, как-то отделить само получение данных из БД (это mysqliшный result) от тех 3 скриптов, занятых только представлением данных. И соединить всё.
Разумеется, непосредственный доступ к модели с клиента запрещен.
Как это лучше сделать?
Если бы делал для себя, то не заморачивался, тупо includeил бы модель в каждый из 3 скриптов.
Но, мой код будут оценивать Серьезные Западные Синьоры, вот думаю, может, лучше иначе как, может, есть какое общепринятое решение типа паттерна?

Хотелось бы без MVC-фреймворков (это уже специфика проекта).
Хотя и MVC как-то мало упростил бы дело... Идея-то ясна: 1 Model, 3 Action/View, но - коряво выглядит... Или нет?

Answer 1

[Олег Красавин]

Если собрались делать нормальный REST, то отдавайте в том формате, который запрашивает юзер в заголовке `Accept`, например Accept: text/plain

Comments

[Сергей Савостин]

Accept: */*
Что отдавать?

[Станислав Макаров]

Сергей Савостин ну если сгодится что угодно (*/*), то и отдавать что угодно (что проще по мнению сервера). А что конкретно отдано, будет понятно по Content-Type).

[VZVZ]

За идею с Accept спасибо, хотя есть у нее минусы.
Неужели вам никогда не приходилось с новым для вас REST API, если оно поддерживает GET (а не POST), экспериментировать прямо в адресной строке браузера?
Мне - да. ИМХО, это быстрейший и простейший способ разобраться с таким API - никаких снифферов, никаких написаний тестов на ЯП...
И вот именно поэтому я за access_token'ы, а не куки или Authorization; и поэтому же я против Accept. Короче, если хоть 1 метод API поддерживает GET-запросы, то я против любых заголовков.
Это - минус Accept'а. А плюсы есть? Если нет, то что же здесь "нормального"?

Ну и вернемся к теме вопроса.
Все-таки я хочу отдельные скрипты.

[Олег Красавин]

VZVZ куков быть в апи вообще не должно, никак и никогда. Потому что оно должно быть stateless. Oauth с accessToken - это ок, да. Но даже в этом случае чтобы его получить без Authorization хедера не обойтись.

Если хотите дебажить в браузере - пожалуйста. Устанавливайте, скажем, Json как дефолтный респонс-тайп и вываливайте клиенту. И уже если ему понадобится там XML или хтмл или еще чего - он вам об этом сам сообщит в заголовке.

[Олег Красавин]

VZVZ а по поводу отдельных скриптов - www.slimframework.com как роутер для небольшого апи идеален на мой взгляд.

[VZVZ]

Олег Красавин: > он вам об этом сам сообщит в заголовке
И как мне сделать, чтобы тестовыe запросы из адресной строки шли с Accept?

В моем варианте (точнее, не моем, а в слизанном мной у VK) это не нужно, все просто:
api.vk.com/method/users.get?user_ids=58756174
...вжииииииик:
api.vk.com/method/users.get.xml?user_ids=58756174
И вот он XML.

> без Authorization хедера не обойтись.
Почему именно хедером, почему не параметром GET-запроса?
Это какой-то негласный стандарт? Откуда ноги растут?
Или вы просто действуете по принципу "а что тут думать? раз есть фича - юзать надо!"

> а по поводу отдельных скриптов - www.slimframework.com как роутер для небольшого апи
Спс, глянем.

[VZVZ]

Олег Красавин: > Потому что оно должно быть stateless
Почитал, что такое "stateless". Если правильно понял, то для этого на сервере не должно храниться никакой информации о сессии клиента.
Но как это вообще возможно? Ведь токен - это тоже инфа о сессии по сути. Если не хранить его на сервере, как тогда сервер будет проверять токен не expired ли и валидный ли вообще?

[Олег Красавин]

VZVZ Да, это стандарт. Почитайте официальный RFC на Oauth2 https://tools.ietf.org/html/rfc6749#section-4.1.3

>И как мне сделать, чтобы тестовыe запросы из адресной строки шли с Accept?
Простым switch(). Если там конкретно Accept: application/xml то вываливайте хмл, в любом другом случае вываливайте JSON.

Но безусловно можно пойти и сделать как у VK: парсить request и брать запрашиваемый формат оттуда.

[Олег Красавин]

VZVZ:
>Ведь токен - это тоже инфа о сессии по сути.
Не совсем, это инфа о клиенте прежде всего. Хранить его на сервере можно и даже нужно(иначе никак). По нему как раз идет аутентификация.

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

[VZVZ]

Олег Красавин: > Да, это стандарт. Почитайте официальный RFC на Oauth2
Во-первых, разве REST API обязательно предусматривает именно OAuth? Если тот же самый токен выдавать по логин-паролю юзера, без Applicationов и иже с ними, то это не REST API уже?
Во-вторых, может, я слепой, но я не вижу по вашей ссылке никаких упоминаний HTTP-заголовка "Authorization". Само слово "authorization" там встречается однократно, но почему нужно делать именно вот так (пример из Twitter):
POST /oauth2/token HTTP/1.1
Host: api.twitter.com
User-Agent: My Twitter App v1.0.23
Authorization: Basic eHZ6MWV2RlM0d0VFUFRHRUZQSEJvZzpMOHFxOVBaeVJn
NmllS0dFS2hab2xHQzB2SldMdzhpRUo4OERSZHlPZw==Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Content-Length: 29
Accept-Encoding: gzip

grant_type=client_credentials
Об этом я там ни слова не вижу.

> Простым switch()
Я не про обработку серваком, а про то, как послать этот Accept, если я в адресной строке браузера вбиваю такое:
root/images.get?blabla=123456&token=uhygtfiyuijiphoyui
и хочу получить в окне браузера именно XML, тогда как по дефолту оно выдает JSON.
Вы, я вижу, вообще не понимаете, зачем какие-то запросы к REST API нужно делать из адресной строки :)
А ведь это реально удобно, а главное, очень просто - для 3rd-party новичков, которые будут с моим API работать.

> То есть результат запроса с любого устройства/места/планеты должен быть предсказуем.
Ну, если я пошлю те же самые куки, то он будет предсказуем.

Answer 2

[Игорь]

И все же лучше один скрипт. Который делает один и тот же запрос, создавая один и тот же объект.ну модель.
или раз хотите 3 скрипта то этот один инклюдите. и потом уже объект приводите к виду что отдавать хотите. в разных скриптах по своему получается.