Стоит ли начинать разработку сайта сразу с API?

Question

[Вася Фамилия]

Идея написать сразу API для сайта. Ну, например выбрать 10 новостей, в нужном формате:
для этого делаем GET-запрос get=news&limit=10&type=json оформляем его как нам угодно.
В итоге получаем 10 новостей в json массиве с нужной информацией. Вижу одни плюсы от такой разработки - например, можно сменить фреймворк или даже язык, не трогая фронтенд.
Применяется такой подход к проектированию? И может есть готовые решения, о которых можно почитать. Или есть какие то существенные минусы о которых я не догадываюсь?

Comments

[Ба Ань Доан]

Клиент-сервер подход успешно применяется в RESTful

[sim3x]

Почитайте, как делают пути в апи и как вообще выглядит работа с ним
У вас какой-то sql over http получается

[kulaeff]

Вы вроде бы говорите об SPA.

Answer 1

[Евгений Вольф]

например можно не трогая фронтенд сменить фреймворк или даже язык.

В большинстве случаев, можно сменить фреймворк не трогая фронтэнд. Например, если Ваш фреймворк использует шаблонизатор "Twig". В некоторых случаях, так же можно сменить язык, подвергая шаблоны минимальной модификации, которую можно провести через "Найти/Заменить". Но, я бы на Вашем месте не сильно обольщался на эту "возможность".

Ну например выбрать 10 новостей в нужном формате
делаем GET запрос

Обычно делают POST-запрос, и не в формате адресной строки (GET-параметров), а отправляется так же, запрос в формате JSON. Обратите внимание на ключевое слово "обычно", т.е. не всегда.

Применяется такой подход к проектированию?

Это скорее подход к разработке, уровня "клиент-сервер", и/или REST API.

И может есть готовые решения о которых можно почитать.

Не совсем понятно, какое именно готовое решение Вы хотите получить. HTTP-клиенты и обработка JSON-данных, встроена во многие языки, или реализована в виде готовых библиотек.

Или есть какие то существенные минусы о которых я не догадываюсь?

Если Вы хотите разработать, например, настольное или телефонное (как пример) приложение-клиент, то это один из лучших вариантов. Если же Вы хотите построить по такому принципу обычный сайт, то Вы просто введёте новый уровень абстракции и новое звено в цепочку, чем усложните работу самому себе, а так же потенциально замедлите работу проекта.

Насколько я понимаю, Вы хотите обернуть РСУБД (SQL-БД), работающую через (unix-)сокет, в более примитивные API, выдающие ответы в формате JSON? А чем Вас ответ в формате "SQL result resource" не устроил? :) При использовании РСУБД (и не только) Вы так же можете сменить и шаблонизатор, и фреймворк и язык и всё остальное, а необходимый функционал написать на уровне самой БД, в виде хранимых функций/процедур, без дополнительных, ненужных цепочек передачи данных.

Comments

[jasonOk]

Обычно делают POST-запрос, и не в формате адресной строки (GET-параметров), а отправляется так же, запрос в формате JSON. Обратите внимание на ключевое слово "обычно", т.е. не всегда.

Почему POST и для чего тогда вы используете GET запросы?

[Евгений Вольф]

Почему POST и для чего тогда вы используете GET запросы?

POST, по тому, что при обмене данными в формате JSON, вполне логично отправлять эти данные в таком формате в обе стороны, и в этом случае, POST-запрос выглядит гораздо более приемлемо.

В остальном, - исключительно по желанию разработчика, ему принципиально нравится GET-вариант? Без проблем.

[Александр Филиппенко]

Если опираться на стандарты REST, то должен быть всё-таки GET запрос, только что-то вроде
/api/v1/news/?limit=10&offset=20
Использовать JSON в POST для сохранения данных - логично, и это обычная практика. Но для получения - очень странно. Хотя работать будет конечно.
Про RESTful ниже написали. По-моему очень простой и логичный стандарт.

[Евгений Вольф]

Если опираться на стандарты REST, то должен быть всё-таки GET запрос, только что-то вроде
/api/v1/news/?limit=10&offset=20

Возможно Вы правы, но я нашел в википедии, вот чего:

Все ресурсы идентифицируются в запросах, например, с использованием URI в интернет-системах.

, где ключевое слово - например, то есть, насколько я понимаю, "например != желательно/обязательно".

Answer 2

[Артем Лисовский]

Api стоит делать, если:

• вы делаете какой-то сервис, подразумевающий пользовательскую интеграцию
  
• вы делаете front-end асинхронным(аля SPA, angular/react/backbone)
  
• вы планируете сделать приложение или прочее интегрированное решение
  

В остальных случаях api как первый шаг - так себе бизнес-задача.

Answer 3

[Ярослав Сиваков]

Такой подход применяется, на сколько я могу судить, для очень многих современных сайтов-приложений. Берётся js-фреймворк, который работает "сам по себе" на клиенте (т.е. в браузере). Отдельно делается серверная часть - как раз с API, через который клиент получается данные. Почитайте про Angular и React (касательно фронтенда) и про REST (касательно бекенда).