Требуется ли использовать папку сервера в Nuxt 3, когда у нас есть конечные точки API?
У нас есть папка server в Nuxt 3. В ней есть папка api. почему мы должны использовать его, если у нас есть конечные точки API, использующие серверный язык программирования? они связаны между собой или нет?
например, у нас есть конечные точки, созданные с помощью Laravel:
http://www.example.com/product
http://www.example.com/product/1
Мы можем вызвать эти конечные точки, используя useFetch или $fetch, чтобы использовать их данные. здесь обязательно использовать папку server/api?
например, у нас есть такие папки и файлы:
server/api/product/index.get.ts
server/api/product/[productId]/index.get.ts
Вы можете помочь мне? они связаны между собой или нет? в какое время нам следует использовать папку server?
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 3
Все зависит от вашего проекта. Если вы получаете свои данные непосредственно из конечной точки laravel, нет смысла заполнять и использовать папку API.
Это два разных подхода к использованию API с Nuxt. Если вы разрабатываете полнофункциональное приложение, в котором интерфейс и серверная часть тесно связаны, имеет смысл создать конечные точки непосредственно в каталоге сервера.
Если в вашем случае у вас отдельный фронтенд и бэкенд. Тогда использование каталога сервера будет ненужным. Было бы неплохо, если бы вы захотели создать простую конечную точку, напрямую связанную с приложением Nuxt. Вариантом использования может быть аутентификация/авторизация с точки зрения безопасности.
Этот пост может быть полезен: Должен ли я создавать серверную часть приложения внутри каталога сервера nuxt.js?
У каталога сервера есть еще одно преимущество. Все запросы направляются на сервер Nuxt, который расположен по адресу внешнего интерфейса. Например, ваш интерфейс расположен по адресу http://www.example-front.com , а ваш сервер — http://www.example-backend.com , если вы делаете запрос на http ://www.example-front.com/server/api/product/ и внутри него сделайте запрос к вашему бэкенду, тогда из браузера мы не увидим реальный адрес вашего серверного приложения, это помогает скрыть API конечная точка. Вы также можете отформатировать ответ от вашего сервера до нужного вам типа (например, скрыть некоторые поля) и теперь в браузере будет виден отформатированный ответ.
Просто совет: домен example.com на самом деле специально зарезервирован для примеров, и они гарантируют, что домен никогда не будет выдан. Поэтому вместо использования www.example-backend.com лучше было бы использовать домен backend.example.com. Это всего лишь придирка, но мне кажется интересным, что IANA (?) предвидела необходимость указать примеры URL-адресов и фактически зарезервировала для них домен.
Ваш ответ можно улучшить, добавив дополнительную вспомогательную информацию. Пожалуйста, отредактируйте , добавив дополнительную информацию, например цитаты или документацию, чтобы другие могли подтвердить правильность вашего ответа. Более подробную информацию о том, как писать хорошие ответы, вы можете найти в справочном центре.