Принципы REST_API: 1) Клиент-серверная модель взаимодействия 2) Отсутствие состояния 3) Унификация интерфейса 4) Кеширование 5) Формат обмена данными (JSON, XML)
Спасибо за видео! Но я все равно не понимаю))) вот почему считается, что нельзя передавать тело запроса в get запросе? А есть техническая разница между post и гет запросом когда в теле передаем? Или например разница между put и post. Там технической разницы же вообще нет) реализацию «не изменения» таких же данных можно и в post реализовать, будет тоже самое, что и задумывалось в put. Получается это только «так можно а так нельзя»
Спасибо за коммент) В get запросе тела просто нет, поэтому его нельзя передать. Между put и post как таковой технической разницы нету, однако по архитектурному стилю put используется для обновления объекта, тогда как post для создания, а patch для частичного обновления. Такое разделение сделано как раз для того, что бы можно было определить тип операции, который необходимо выполнить: создание, полное обновление или частичное)
Это утверждение противоречит основным принципам современной разработки API и безопасности. В реальности API-серверы используют различные методы для идентификации и аутентификации клиентов, чтобы обеспечить безопасное и эффективное взаимодействие. Например, серверы часто используют механизмы авторизации, такие как токенизация и API-ключи, которые позволяют идентифицировать и аутентифицировать клиентов при каждом запросе. Это позволяет серверу управлять доступом к ресурсам и защищать данные от несанкционированного доступа. Утверждение о том, что сервер не "запоминает" информацию о клиенте, не соответствует реальной практике разработки API и безопасности информационных систем.
Термин “stateless” вам о чем нибудь говорит?) Сервис АПИ не хранит инфо о пользователе, в отличие от сервера или самого приложения с базой данных и тд)
Наконец то, первое последовательное, простое объяснение без воды! Спасибо!
Благодарю)
Благодарю ! Классный формат подачи - спокойный, без воды. В общем - ПОЛЬЗА! 👍👍👍
Благодарю)
Принципы REST_API:
1) Клиент-серверная модель взаимодействия
2) Отсутствие состояния
3) Унификация интерфейса
4) Кеширование
5) Формат обмена данными (JSON, XML)
Все верно)
@@eager4IT, это не просто верно, но и намного короче.
@@alexey.kondakov правда?... и информативнее? и о чем этот список без примеров должен сказать новичку?...🤔
@@AA-kb8vy, какой из этих элементарных пунктов будет непонятен новичку без примеров?
@@alexey.kondakov 😂
Огромная благодарность
Всегда пожалуйста)
Спасибо
Пожалуйста)
Здравствуйте "Хочу вАйти" - я бы хотел увидеть такую вот тему - pipe line/ ci cd
Здравствуйте! Отличная тема, сделаем)
Спасибо! Теперь точно дошло
😂
Спасибо, в точку!
Пожалуйста 🙂
Спасибо за видео! Но я все равно не понимаю))) вот почему считается, что нельзя передавать тело запроса в get запросе? А есть техническая разница между post и гет запросом когда в теле передаем?
Или например разница между put и post. Там технической разницы же вообще нет) реализацию «не изменения» таких же данных можно и в post реализовать, будет тоже самое, что и задумывалось в put.
Получается это только «так можно а так нельзя»
Спасибо за коммент)
В get запросе тела просто нет, поэтому его нельзя передать.
Между put и post как таковой технической разницы нету, однако по архитектурному стилю put используется для обновления объекта, тогда как post для создания, а patch для частичного обновления.
Такое разделение сделано как раз для того, что бы можно было определить тип операции, который необходимо выполнить: создание, полное обновление или частичное)
Расскажите о API на примере, Честный Знак)))
Что именно вас интересует?)
@@eager4IT пример запроса, информация о sgtin
Норм
Благодарю
Это утверждение противоречит основным принципам современной разработки API и безопасности. В реальности API-серверы используют различные методы для идентификации и аутентификации клиентов, чтобы обеспечить безопасное и эффективное взаимодействие. Например, серверы часто используют механизмы авторизации, такие как токенизация и API-ключи, которые позволяют идентифицировать и аутентифицировать клиентов при каждом запросе. Это позволяет серверу управлять доступом к ресурсам и защищать данные от несанкционированного доступа. Утверждение о том, что сервер не "запоминает" информацию о клиенте, не соответствует реальной практике разработки API и безопасности информационных систем.
Термин “stateless” вам о чем нибудь говорит?)
Сервис АПИ не хранит инфо о пользователе, в отличие от сервера или самого приложения с базой данных и тд)
were's secrets?
inside 🙂
А где секреты?!
В видео))
какая-то не секретная информация
Отчасти))