я немного не понял, буду благодарен тому, кто подскажет, вот автор говорит api/v1/users/1/adress неправильно, надо api/v1/users-with-adress, потому что якобы получится сложный путь, но почему он дальше показывает api/v1/users/1/wallets.. почему для адреса плохо, а для кошельков нормально
сам по себе api/v1/users/1/adress не неправильный, если вам надо получить только адрес юзера без данных самого юзера, то вы будете пользоваться этим запросом. Но если вам надо получить и данные самого юзера, и его адрес, то без users-with-adress вам придется выполнить 2 запроса: 1. получить данные юзера вызвав api/v1/users/1; 2. получить адрес юзера вызвав pi/v1/users/1/adress. Чтобы сделать это одним запросом вы создаете users-with-adress и одним запросом api/v1/users-with-adress получаете и данные юзера и его адрес. В примере с кошельками не стояло задачи получить одновременно и данные пользователя, и данные его кошельков, а только кошельки, поэтому запрос api/v1/users/1/wallets. Если вам понадобится получить одновременно и данные пользователя, и данные его кошельков, то вероятно здесь вы по аналогии создадите users-wallets и будете в одном запросе возвращать и данные пользователя, и список всех его кошельков
Потому что леха гонит. И он действительно в работе идет от код ферст. Т.е они чота кодят, потом костылят. Вот этот юзер с адресс и есть типичный костыль Продумывать апи надо вначале
Очень очень мало объяснений почему так надо делать, а почему не надо. Объяснения в стиле "так хорошо, а так плохо", как для маленьких детей. Или "потому что с вами не захотят работать". Автор, почему ты так не уважаешь аудиторию?
Во всех примерах "неправильно" приводит к тому, что в OPEN API будет сгенерирован один ресурс, где внутри будет куча описания. С таким крайне неудобно и тяжело работать, особенно в примерах, озвученных позже (генерация кода и mock postman по OPEN API).
Не соглашусь с вами. Ошибается тот кто ничего не делает. Автор сказал, что рассказывает все поверхностно, верхнеуровнево. На подобных выступлениях обычно, устанавливают определенный тайминг по времени, по этому все довольно емко. Для подробного разбора по каждому блоку прибавляйте по часу, вот вам и будет курс.
я немного не понял, буду благодарен тому, кто подскажет, вот автор говорит api/v1/users/1/adress неправильно, надо api/v1/users-with-adress, потому что якобы получится сложный путь, но почему он дальше показывает api/v1/users/1/wallets.. почему для адреса плохо, а для кошельков нормально
сам по себе api/v1/users/1/adress не неправильный, если вам надо получить только адрес юзера без данных самого юзера, то вы будете пользоваться этим запросом. Но если вам надо получить и данные самого юзера, и его адрес, то без users-with-adress вам придется выполнить 2 запроса: 1. получить данные юзера вызвав api/v1/users/1; 2. получить адрес юзера вызвав pi/v1/users/1/adress. Чтобы сделать это одним запросом вы создаете users-with-adress и одним запросом api/v1/users-with-adress получаете и данные юзера и его адрес. В примере с кошельками не стояло задачи получить одновременно и данные пользователя, и данные его кошельков, а только кошельки, поэтому запрос api/v1/users/1/wallets. Если вам понадобится получить одновременно и данные пользователя, и данные его кошельков, то вероятно здесь вы по аналогии создадите users-wallets и будете в одном запросе возвращать и данные пользователя, и список всех его кошельков
А если кроме адреса еще много-много разных присоединенных объектов нужно получить, то какой path будет?@@karpukolga4326
Потому что леха гонит.
И он действительно в работе идет от код ферст. Т.е они чота кодят, потом костылят. Вот этот юзер с адресс и есть типичный костыль
Продумывать апи надо вначале
@@karpukolga4326 У меня больше вопрос про users-with-adress, получается создается новое представление в таблице БД именно по этому запросу?
Лайк
Очень очень мало объяснений почему так надо делать, а почему не надо. Объяснения в стиле "так хорошо, а так плохо", как для маленьких детей. Или "потому что с вами не захотят работать". Автор, почему ты так не уважаешь аудиторию?
присоединяюсь к вопросу
Во всех примерах "неправильно" приводит к тому, что в OPEN API будет сгенерирован один ресурс, где внутри будет куча описания. С таким крайне неудобно и тяжело работать, особенно в примерах, озвученных позже (генерация кода и mock postman по OPEN API).
и почему изменение баланса через POST а не PUT
Как я поняла, потому что PUT предполагает отправку образа всего обьекта, а не его части. Возможно в данном кейсе стоило заменить на PATCH
@@v.belova Вот тут тоже согласен
Качество выступления крайне низкое. Нужно готовиться лучше - перепутанные слайды тому подтверждение. Лектор не ценит и не уважает свою аудиторию
Не соглашусь с вами. Ошибается тот кто ничего не делает.
Автор сказал, что рассказывает все поверхностно, верхнеуровнево.
На подобных выступлениях обычно, устанавливают определенный тайминг по времени, по этому все довольно емко.
Для подробного разбора по каждому блоку прибавляйте по часу, вот вам и будет курс.
@@radnass6568 ваш тезис про ёмкий рассказ не противоречит моему утверждению о низком качестве выступления. Перепутанные слайды тому подтверждение.