Где различие между веб-приложением и API?

Question

Этот вопрос тесно связан с это вопрос . Я задаю другой вопрос. Я все еще немного запутался в topi c.

Проблема, с которой я столкнулся

В настоящее время у меня есть веб-приложение Django, где пользователи могут иметь список их хобби и может увеличивать счетчик каждый раз, когда они делают одно из своих хобби. Моя проблема в том, что я хочу расширить эту функциональность за пределы интерфейса. Другими словами, я хочу, чтобы пользователи могли увеличивать свои хобби, используя POST запрос, скажем, из терминала, из своего собственного скрипта или чего-то еще.

Где я в замешательстве

Нужно ли создавать API для моего веб-приложения, чтобы добавить эту функцию?

Другой способ сделать это, мне нужно обрабатывать запросы, поступающие из внешнего интерфейса, иначе, чем запросы, поступающие откуда-то еще? Будут ли внешние запросы go на URL www.hostname.com/hobbies/1 и другие запросы go на URL www.hostname.com/api/hobbies/1?

Если я перенаправлю запросы POST на тот же URL-адрес, что и запросы, поступающие из внешнего интерфейса (т. Е. www.hostname.com/hobbies/1), то почему у Google есть внешние API для Google Maps ? Похоже, что если другие веб-приложения вызывают функции Google Maps, то Google отделил эти экземпляры от их внешнего интерфейса.

Answer 1

Моя проблема в том, что я хочу расширить эту функциональность за пределы интерфейса. Другими словами, я хочу, чтобы пользователи могли увеличивать свои увлечения, используя POST-запрос, скажем, из терминала или из своего собственного скрипта или чего-то еще.

Нужно ли создавать API для моего веб-приложения, чтобы добавить это функционал?

Скорее всего да. Для этого есть несколько причин:

1) Запрос POST от терминала / сценария, скорее всего, завершится неудачно для вашей конечной точки /hobbies/1/ из-за Django защиты CSRF . Вам нужен другой тип аутентификации и авторизации для запросов вне вашего приложения.

2) Скорее всего, запрос POST от терминала / скрипта будет иметь это контент, закодированный как JSON, в то время как запрос POST, отправленный через форму html, будет иметь контент, закодированный как x-www-form-urlencoded. Это требует совершенно другого типа проверки и обработки ошибок в качестве ответа, который приводит нас к 3).

3) Запрос POST к вашей конечной точке /hobbies/1/, скорее всего, вернет ответ HTML, который это не то, что хотел бы получить ваш терминал / скрипт, скорее всего, они захотят получить более структурированный тип данных, такой как JSON.

Объединение решений для 1) + 2) + 3) дать вам /api/hobbies/1/.