📚 REST API - архитектурный стиль, но не протокол 📚
REST API — это архитектурный стиль для создания веб-сервисов, основанный на протоколе HTTP.
То, что REST API основан на протоколе HTTP, означает, что все принципы работы, структура запросов и ответов, будут также применимы и для REST API.
Архитектурный стиль REST приносит для HTTP дополнительные правила и принципы, по которым должен происходить обмен данными в Интернете 👇
Главные принципы REST:
1. Строгое разделение клиента и сервера
2. Единый интерфейс
3. Без сохранения состояния (Stateless)
4. Многоуровневая система
5. Кэширование
6. Выполнение кода по запросу
В картинках к посту просто и с примерами разобрала эти принципы. Сохраняйте и пользуйтесь 🤍
Это не самая ценная в работе информация, но перечень этих принципов и их понимание могут спрашивать на собеседованиях 📚
#RestApiGA
REST API — это архитектурный стиль для создания веб-сервисов, основанный на протоколе HTTP.
То, что REST API основан на протоколе HTTP, означает, что все принципы работы, структура запросов и ответов, будут также применимы и для REST API.
Архитектурный стиль REST приносит для HTTP дополнительные правила и принципы, по которым должен происходить обмен данными в Интернете 👇
Главные принципы REST:
1. Строгое разделение клиента и сервера
2. Единый интерфейс
3. Без сохранения состояния (Stateless)
4. Многоуровневая система
5. Кэширование
6. Выполнение кода по запросу
В картинках к посту просто и с примерами разобрала эти принципы. Сохраняйте и пользуйтесь 🤍
Это не самая ценная в работе информация, но перечень этих принципов и их понимание могут спрашивать на собеседованиях 📚
#RestApiGA
❤44👍16🔥9👏1🤔1
🤩 Структура методов REST API в одной картинке 🤩
Коллеги, публикую для вас картинку-шпаргалку, которую можно использовать при проектировании методов REST API 🙌
Эта задача актуальна для старших системных аналитиков, которые работают с Backend-командами, с мобильной разработкой, в проектах с микросервисной архитектурой или в других сложных проектах, где нужно проектировать и описывать процесс обмена данными между системами.
А чтобы вы наглядно могли сопоставить структуру на картинке с реальными REST API, предлагаю вам посмотреть примеры открытой API-документации для интеграции с крупными сервисами:
Avito Доставка
ЦИАН
#RestApiGA
Коллеги, публикую для вас картинку-шпаргалку, которую можно использовать при проектировании методов REST API 🙌
Эта задача актуальна для старших системных аналитиков, которые работают с Backend-командами, с мобильной разработкой, в проектах с микросервисной архитектурой или в других сложных проектах, где нужно проектировать и описывать процесс обмена данными между системами.
А чтобы вы наглядно могли сопоставить структуру на картинке с реальными REST API, предлагаю вам посмотреть примеры открытой API-документации для интеграции с крупными сервисами:
Avito Доставка
ЦИАН
#RestApiGA
🔥24❤9👍4
🪫 Есть ли этот самый Work&Life balance? 🔋
Я всегда работала очень много. 70-часовая рабочая неделя какое-то время была моей "ненормальной нормой". Всякое бывало. И положительные результаты от этого я тоже вижу. Но…
Может показаться, что чем больше работаешь, тем больше успеваешь, но это ловушка. Рано или поздно понимаешь: так дальше нельзя 😰 Когда ты перерабатываешь, страдает здоровье, и страдает сама работа. Усталость и недосып не проходят бесследно — качество выполнения задач падает, настроение ужасное.
Если я сижу за компьютером 12 часов подряд, это не значит, что я много успеваю и действительно эффективна. Это бывает вынужденно, когда задач перебор. И я ощущаю, как скорость работы моего мозга начинает стремиться к нулю.
Нет души в работе, когда ты выжат, как лимон. Это плохое состояние. И я думаю оно периодически настигает каждого из нас.
Что я поняла? 👇
Всякое бывает. И переработки, и учеба. Всё это может увеличивать рабочие дни. Главное, чтобы эти переработки не были ежедневно. И делать полноценные выходные без компьютера.
Нужно не просто работать больше, а работать лучше. Качество важнее количества. А чтобы сохранять это качество, нужно давать себе отдых, спать достаточно, ставить границы.
Мои лайфхаки по установкам границ в Work&Life balance:
1. Заняла время тренировками каждый день.
2. Прогулки и перерывы каждые 90 минут.
3. Сейчас у меня два полных выходных. Скажу честно - пока это стоит мне распределения 50-60 часов задач в 5 дней. Что бывает тяжело. Но это перепланирование последних месяцев заставляет мой мозг искать решения.
4. Планирую максимум две задачи в день, одну из которых можно не успеть.
Берегите себя. Работа — это важно, но выгорание никого до добра не доводило.
В мире, где все вокруг стремятся успеть больше, иногда лучше остановиться и перевести дыхание. И это нормально ❤️
Я всегда работала очень много. 70-часовая рабочая неделя какое-то время была моей "ненормальной нормой". Всякое бывало. И положительные результаты от этого я тоже вижу. Но…
Может показаться, что чем больше работаешь, тем больше успеваешь, но это ловушка. Рано или поздно понимаешь: так дальше нельзя 😰 Когда ты перерабатываешь, страдает здоровье, и страдает сама работа. Усталость и недосып не проходят бесследно — качество выполнения задач падает, настроение ужасное.
Если я сижу за компьютером 12 часов подряд, это не значит, что я много успеваю и действительно эффективна. Это бывает вынужденно, когда задач перебор. И я ощущаю, как скорость работы моего мозга начинает стремиться к нулю.
Нет души в работе, когда ты выжат, как лимон. Это плохое состояние. И я думаю оно периодически настигает каждого из нас.
Что я поняла? 👇
Всякое бывает. И переработки, и учеба. Всё это может увеличивать рабочие дни. Главное, чтобы эти переработки не были ежедневно. И делать полноценные выходные без компьютера.
Нужно не просто работать больше, а работать лучше. Качество важнее количества. А чтобы сохранять это качество, нужно давать себе отдых, спать достаточно, ставить границы.
Если ты не ставишь рамки, никто за тебя это не сделает.
Мои лайфхаки по установкам границ в Work&Life balance:
1. Заняла время тренировками каждый день.
2. Прогулки и перерывы каждые 90 минут.
3. Сейчас у меня два полных выходных. Скажу честно - пока это стоит мне распределения 50-60 часов задач в 5 дней. Что бывает тяжело. Но это перепланирование последних месяцев заставляет мой мозг искать решения.
4. Планирую максимум две задачи в день, одну из которых можно не успеть.
Если вы сейчас постоянно много работаете — задумайтесь, что ваша усталость не делает счастливыми ни вас, ни окружающих.
Берегите себя. Работа — это важно, но выгорание никого до добра не доводило.
В мире, где все вокруг стремятся успеть больше, иногда лучше остановиться и перевести дыхание. И это нормально ❤️
❤72👍15❤🔥14
🤝 Связь CRUD-модели и методов REST API 🤝
Работая над задачами связанными с определением функциональности, я всегда использую CRUD-модель, которая легко сопоставляется с методами REST API:
C - Create - Создать - POST / PUT
R - Read - Читать / Смотреть / Получить - GET / POST в искл. случаях
U - Update - Изменить - PATCH / PUT
D - Delete - Удалить - DELETE / PATCH в случаях архивации
При анализе требований я прогоняю эти действия над каждой сущностью, данные о которой должны храниться в БД системы.
❗️Важно помнить, что эту модель нужно прогнать не только для ОДНОГО объекта, но и для МНОГИХ.
❗️Важно уточнять, кто и когда это будет делать.
Статья по созданию CRUD-модели с подробным разбором примера доступна по этой ссылке.
В работе CRUD помогает мне не упустить функциональные требования из виду, уточнить требования к данным в БД и получить уточняющие вопросы по процессам.
Используйте её, чтобы структурировать процесс работы с функциональными требованиями 🙌
#RestApiGA
Работая над задачами связанными с определением функциональности, я всегда использую CRUD-модель, которая легко сопоставляется с методами REST API:
C - Create - Создать - POST / PUT
R - Read - Читать / Смотреть / Получить - GET / POST в искл. случаях
U - Update - Изменить - PATCH / PUT
D - Delete - Удалить - DELETE / PATCH в случаях архивации
При анализе требований я прогоняю эти действия над каждой сущностью, данные о которой должны храниться в БД системы.
❗️Важно помнить, что эту модель нужно прогнать не только для ОДНОГО объекта, но и для МНОГИХ.
❗️Важно уточнять, кто и когда это будет делать.
Статья по созданию CRUD-модели с подробным разбором примера доступна по этой ссылке.
В работе CRUD помогает мне не упустить функциональные требования из виду, уточнить требования к данным в БД и получить уточняющие вопросы по процессам.
Используйте её, чтобы структурировать процесс работы с функциональными требованиями 🙌
#RestApiGA
👍28❤11❤🔥5😁1
💫 Открыта запись на практическую программу REST API 💫
Если вы недавно интересовались актуальными требованиями к Системным аналитикам, то наверняка видели:
+ Знание стандартов REST API (JSON);
+ Опыт проектирования API;
+ Опыт проектирования и документирования REST сервисов (JSON);
+ Понимание принципов работы мобильных приложений;
+ Навык проектирования REST API (описание с использованием OpenAPI Specification);
+ Навык тестирования API Backend (Postman);
+ Знание Swagger для создания REST API документации;
Все эти навыки, в разных формулировках, ожидают от Middle и Senior Cистемных аналитиков, которым предстоит работать с Backend- или мобильными командами, в проектах с интеграциями.
Мы осваиваем их на практике в рамках одного большого проекта на программе:
💻 Дизайн REST API
🗓 Старт 5 ноября
В ходе работы учимся проектировать методы REST API с нуля, глядя на требования, архитектуру, БД и дизайн UI/UX системы.
Проект с подвохами и сложностями, на котором “набиваем шишки”, учимся писать с нуля и структурировать API-документацию, осваиваем ключевые инструменты Системных аналитиков 🛠
👉 В результате вы создаете свой проект API-документации в Postman и умеете запустить работающие REST API методы Backend на заглушках, даже без навыков программирования! 🤩
Это самая весомая и “программистская” часть вашего профессионального портфолио.
🗓 До 25 октября:
Запись на специальных условиях с дополнительным обучением по БД в подарок, знания которой понадобятся в ходе работы на проекте.
Нужна консультация или есть вопросы? Пишите @getanalyst или заполняйте анкету предзаписи. Мы свяжемся с вами, поможем оценить текущие навыки и ответим на вопросы! 🤝
Если вы недавно интересовались актуальными требованиями к Системным аналитикам, то наверняка видели:
+ Знание стандартов REST API (JSON);
+ Опыт проектирования API;
+ Опыт проектирования и документирования REST сервисов (JSON);
+ Понимание принципов работы мобильных приложений;
+ Навык проектирования REST API (описание с использованием OpenAPI Specification);
+ Навык тестирования API Backend (Postman);
+ Знание Swagger для создания REST API документации;
Все эти навыки, в разных формулировках, ожидают от Middle и Senior Cистемных аналитиков, которым предстоит работать с Backend- или мобильными командами, в проектах с интеграциями.
Мы осваиваем их на практике в рамках одного большого проекта на программе:
💻 Дизайн REST API
🗓 Старт 5 ноября
В ходе работы учимся проектировать методы REST API с нуля, глядя на требования, архитектуру, БД и дизайн UI/UX системы.
Проект с подвохами и сложностями, на котором “набиваем шишки”, учимся писать с нуля и структурировать API-документацию, осваиваем ключевые инструменты Системных аналитиков 🛠
👉 В результате вы создаете свой проект API-документации в Postman и умеете запустить работающие REST API методы Backend на заглушках, даже без навыков программирования! 🤩
Это самая весомая и “программистская” часть вашего профессионального портфолио.
🗓 До 25 октября:
Запись на специальных условиях с дополнительным обучением по БД в подарок, знания которой понадобятся в ходе работы на проекте.
Нужна консультация или есть вопросы? Пишите @getanalyst или заполняйте анкету предзаписи. Мы свяжемся с вами, поможем оценить текущие навыки и ответим на вопросы! 🤝
👍9❤4
GetAnalyst_Пошаговый_план_Проектирования_REST_API_методов_с_примером.pdf
1.7 MB
✅ REST API - пошаговый план проектирования методов с нуля + пример ✅
Для проектирования REST API методов рекомендуется использовать пошаговый подход:
0. Выбор сущности — определите, для какой сущности разрабатывается API-метод.
1. Анализ потребностей клиента — выясните, какие данные и функциональность требуются на всех экранах, связанных с сущностью. Это поможет создать универсальный JSON-объект (body), который можно использовать для всех операций CRUD-модели.
2. Сопоставление с БД — проверьте, какие данные уже есть в базе данных, и какие необходимо добавить для реализации метода.
3*. Доработка БД — добавьте недостающие таблицы и поля, если это необходимо.
4*. Требования к интеграции — если данные должны поступать из внешней системы или отправляться в неё, учтите это в разработке.
5. Определение доступа — задайте роли пользователей, которым будет доступен API-метод.
6. Алгоритм работы (Use Case) — опишите логику работы метода, включая все возможные ошибки.
7. Проектирование запроса REST API — определите метод (GET, POST и т.д.), URL, заголовки (headers) и тело (body) запроса.
8. Проектирование успешного ответа — укажите HTTP-статус, заголовки и тело ответа.
9. Проектирование ошибок — опишите неуспешные ответы: HTTP-статус, заголовки и тело для каждой ошибки.
* - необязательные пункты, зависят от задачи.
Самые первые и важные шаги - понять потребности клиента и оценить полноту данных в БД. Потому что именно на их основе мы проектируем JSON-структуры данных.
Подготовила для вас мини-книгу с примером применения этой пошаговой инструкции для проекта #RentACar 🙌 Книга прикреплена к посту.
#RestApiGA
Для проектирования REST API методов рекомендуется использовать пошаговый подход:
0. Выбор сущности — определите, для какой сущности разрабатывается API-метод.
1. Анализ потребностей клиента — выясните, какие данные и функциональность требуются на всех экранах, связанных с сущностью. Это поможет создать универсальный JSON-объект (body), который можно использовать для всех операций CRUD-модели.
2. Сопоставление с БД — проверьте, какие данные уже есть в базе данных, и какие необходимо добавить для реализации метода.
3*. Доработка БД — добавьте недостающие таблицы и поля, если это необходимо.
4*. Требования к интеграции — если данные должны поступать из внешней системы или отправляться в неё, учтите это в разработке.
5. Определение доступа — задайте роли пользователей, которым будет доступен API-метод.
6. Алгоритм работы (Use Case) — опишите логику работы метода, включая все возможные ошибки.
7. Проектирование запроса REST API — определите метод (GET, POST и т.д.), URL, заголовки (headers) и тело (body) запроса.
8. Проектирование успешного ответа — укажите HTTP-статус, заголовки и тело ответа.
9. Проектирование ошибок — опишите неуспешные ответы: HTTP-статус, заголовки и тело для каждой ошибки.
* - необязательные пункты, зависят от задачи.
Самые первые и важные шаги - понять потребности клиента и оценить полноту данных в БД. Потому что именно на их основе мы проектируем JSON-структуры данных.
Подготовила для вас мини-книгу с примером применения этой пошаговой инструкции для проекта #RentACar 🙌 Книга прикреплена к посту.
#RestApiGA
🔥46❤🔥16👍14❤4
🔥 ER-диаграмма БД через код за пределами draw.io 🔥
Коллеги, обычно я делюсь этой фишкой на наших практикумах по БД и SQL, работаем с БД в таком же виде на проекте REST API.
Поскольку буду далее разбирать в канале проектирование REST API и его связь с БД, то мне нужно будет постоянно ссылаться на ER-диаграмму. Решила создать её сразу в удобном виде 🤝
🔗 ER-диаграмма проекта #RentACar
Здесь вы сможете увидеть ER-диаграмму проекта.
Наводить на связи и видеть их кратности.
Наводить на поля и видеть их описание (документацию).
🔗 Документация на БД проекта #RentACar
Здесь вы сможете открыть документацию с описанием каждой таблицы БД и её полей.
При просмотре описания таблицы БД увидеть ER-диаграмму только этой таблицы и связанных с ней таблиц.
Буду ссылаться на эти документы.
Всё создано через код. При том максимально понятный интуитивно.
👉 Инструмент: dbdiagram.io
Как вам такое решение по работе с проектированием БД? 🔥
#БДGA
Коллеги, обычно я делюсь этой фишкой на наших практикумах по БД и SQL, работаем с БД в таком же виде на проекте REST API.
Поскольку буду далее разбирать в канале проектирование REST API и его связь с БД, то мне нужно будет постоянно ссылаться на ER-диаграмму. Решила создать её сразу в удобном виде 🤝
Здесь вы сможете увидеть ER-диаграмму проекта.
Наводить на связи и видеть их кратности.
Наводить на поля и видеть их описание (документацию).
Здесь вы сможете открыть документацию с описанием каждой таблицы БД и её полей.
При просмотре описания таблицы БД увидеть ER-диаграмму только этой таблицы и связанных с ней таблиц.
Буду ссылаться на эти документы.
Всё создано через код. При том максимально понятный интуитивно.
👉 Инструмент: dbdiagram.io
Как вам такое решение по работе с проектированием БД? 🔥
#БДGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥56👍20❤9🤔1
🔮 Как найти время на саморазвитие? 🔮
Я человек с кучей идей, и это всегда подталкивает меня к новому. Итог — я постоянно учусь. Да, это сложно, лень пытается взять верх. Но я хорошо знаю себя: если я застряну в зоне комфорта и перестану развиваться, мне станет грустно.
Поэтому, как бы тяжело и лень ни было, я всегда нахожу время для саморазвития. Пусть даже это всего 2-4 часа в неделю — этого достаточно, чтобы постепенно двигаться вперёд.
Что помогает мотивировать себя брать дополнительные задачи на саморазвитие:
1. Чёткое понимание цели
Я всегда думаю, зачем мне это нужно и какой опыт я получу.
Если нет ясной цели, начинать бессмысленно.
2. Планирование времени
Выделяю хотя бы 30 минут в день на обучение, в конкретное время.
Главное — начать. А когда начинаешь, увлекаешься, то можно и растянуть этот процесс.
Слот в календаре очень помогает ставить ✔️ и выполнять задачу.
3. Эксперименты сразу
Если я увидела какую-то интересную статью или обучение, то я стараюсь разбираться сразу.
Да, не всегда получается, но главное — начать. То, что откладываешь "на потом", чаще всего остаётся в далекой неопределённости.
4. Разделение большого на маленькие шаги
Это помогает двигаться постепенно. Маленькие шаги дают ощущение завершённости, а это очень мотивирует.
5. Самостоятельные задачи на саморазвитие лучше планировать на утро. Вечером не сделаю и отложу на потом
И даже когда почти не остаётся сил после большой загрузки по работе, эти небольшие шаги помогают двигаться вперёд. Новый опыт и развитие всегда заряжают энергией. Даже если это всего один маленький шаг, ты понимаешь, что делаешь что-то важное для себя ❤️
Саморазвитие — это не просто хобби или отвлечение, это процесс роста. Пробовать новые направления, осваивать навыки и расширять свой кругозор — всё это открывает новые возможности и делает тебя сильнее.
А главное — это приносит настоящее удовольствие, когда ты видишь, что становишься лучше и развиваешься независимо от рутинных рабочих задач и других обязательств 🙌
Я человек с кучей идей, и это всегда подталкивает меня к новому. Итог — я постоянно учусь. Да, это сложно, лень пытается взять верх. Но я хорошо знаю себя: если я застряну в зоне комфорта и перестану развиваться, мне станет грустно.
Поэтому, как бы тяжело и лень ни было, я всегда нахожу время для саморазвития. Пусть даже это всего 2-4 часа в неделю — этого достаточно, чтобы постепенно двигаться вперёд.
Что помогает мотивировать себя брать дополнительные задачи на саморазвитие:
1. Чёткое понимание цели
Я всегда думаю, зачем мне это нужно и какой опыт я получу.
Если нет ясной цели, начинать бессмысленно.
2. Планирование времени
Выделяю хотя бы 30 минут в день на обучение, в конкретное время.
Главное — начать. А когда начинаешь, увлекаешься, то можно и растянуть этот процесс.
Слот в календаре очень помогает ставить ✔️ и выполнять задачу.
3. Эксперименты сразу
Если я увидела какую-то интересную статью или обучение, то я стараюсь разбираться сразу.
Да, не всегда получается, но главное — начать. То, что откладываешь "на потом", чаще всего остаётся в далекой неопределённости.
4. Разделение большого на маленькие шаги
Это помогает двигаться постепенно. Маленькие шаги дают ощущение завершённости, а это очень мотивирует.
5. Самостоятельные задачи на саморазвитие лучше планировать на утро. Вечером не сделаю и отложу на потом
И даже когда почти не остаётся сил после большой загрузки по работе, эти небольшие шаги помогают двигаться вперёд. Новый опыт и развитие всегда заряжают энергией. Даже если это всего один маленький шаг, ты понимаешь, что делаешь что-то важное для себя ❤️
Саморазвитие — это не просто хобби или отвлечение, это процесс роста. Пробовать новые направления, осваивать навыки и расширять свой кругозор — всё это открывает новые возможности и делает тебя сильнее.
А главное — это приносит настоящее удовольствие, когда ты видишь, что становишься лучше и развиваешься независимо от рутинных рабочих задач и других обязательств 🙌
👍44❤18🔥8
Разбираем на примере методов:
👉 POST /car
👉 GET /car
👉 GET /car/{carId}
Подробности в картинках к посту.
0️⃣ Метод HTTP
Не относится к URL, но тесно связан с ним. Описывала правила выбора в этом посте.
1️⃣ Протокол
В начале любого URL указывается протокол HTTP(s), который обеспечивает передачу данных.
2️⃣ Доменное имя
Основной адрес, по которому можно обращаться к серверу.
3️⃣ Путь (Path)
Путь включает в себя один или несколько сегментов, разделённых слешами (/).
▫️“api” - указатель на каталог API сервера, может быть название вида api. Это необязательный сегмент, может отсутствовать в URL.
▫️имя api - указывает на конкретный интерфейс API, предназначенный для разных пользователей системы.
▫️v1 - версия API, важна для поддержки совместимости с предыдущими версиями.
▫️car - это ресурс, к которому осуществляется доступ. В данном случае “машина”. Может быть во множественном числе (cars).
▫️{carId} - это параметр в пути URL (path-параметр), указывающий на конкретный авто по его id в БД системы. Фигурные скобки {} обозначают переменную часть URL, значение которой должно быть предоставлено клиентом (например, идентификатор 12345).
4️⃣ Query-параметры (Query-parameters)
Дополнительные параметры запроса после ?, необязательны. Если их несколько, то перечисление через символ &.
Обычно используются для фильтров, сортировок и пагинации при получении списков методом GET, но могут быть и в других API-методах.
В примере:
GET …/car?offset=0&limit=10&dateFrom=2024-10-10&dateTo=2024-10-15
👉 ?offset=0&limit=10 указывает на запрос результатов с 0-го, ограниченный 10-ю результатами на страницу. Это два отдельных query-параметра, которые являются элементами пагинации (постраничного получения данных через API).
👉 &dateFrom=2024-10-10&dateTo=2024-10-15 - фильтр на период аренды, даты “с” и “по”.
Это основные элементы URL в REST API, которые помогают точно определить, к какому ресурсу (сущности) должен быть осуществлен доступ 💾
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤30👍20🔥15❤🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
Не отвлекаемся, проходим мимо, фокус на работе 👩💻🧑💻🦭
Настроение понедельника 😁
Настроение понедельника 😁
😁60😍8💯5
GetAnalyst - REST API - Гайд по JSON.pdf
10.2 MB
📘 Руководство по JSON в REST API - что это, зачем и как создавать 📘 + история про собеседования
Нанимаем системного аналитика на проект, где нужно работать с web-, mobile и backend.
Есть публичная REST API-документация. Опубликована на официальном сайте. Протестировать бесплатно нельзя, почитать бесплатно можно.
Все приложения есть в открытом доступе, можно зарегистрироваться и посмотреть что внутри до собеседования.
Для технической части собеседования не придумываем ничего заумного, а даём реальную задачу из проекта:
👌 Тип метода GET выбирают правильно почти всегда.
👌 URL делают, не всегда так, как ожидаем. Но хотя бы понимаем, где придётся доучить.
🥲 А вот когда дело доходит до JSON, то тут мы можем смело принимать решение о продолжении диалога.
🔴 👉 Типичные ошибки и недочеты:
- Незнание типов данных.
- Дата и время - про стандарты ISO не слышали.
- Умение самостоятельно описать только "плоские" объекты данных, без вложенных структур.
- JSON запроса и ответа одинаковые, либо один из них теряется в случае методов, отличных от GET.
- Неумение работать со списками - массивы.
- Нейминг (именование полей) порой заставляет и смеяться, и плакать.
- Отсутствие знаний базовых структур для методов.
+ Незнание инструментов, что сразу показывает отсутствие опыта.
Это самое-самое, что бросается в глаза с первых минут. Давайте не будем допускать их? 🙂
Руководство по JSON, прикрепленный к посту - ваш будущий помощник и ориентир в проектировании API 📘
В нем собрала самое ключевое, чтобы не валить ваши собеседования и качественно выполнять свою работу 🙌
-----
P.S.
И большой намек к этому посту:
🚨 REST API-документацию компании можно изучить до собеседования, если она есть в открытом доступе. Это полезно, чтобы понять, что будут ожидать на практике, и посмотреть на подходы работы в компании.
-----
Запоминаем, сохраняем, пользуемся 🙏
#RestApiGA
Нанимаем системного аналитика на проект, где нужно работать с web-, mobile и backend.
Есть публичная REST API-документация. Опубликована на официальном сайте. Протестировать бесплатно нельзя, почитать бесплатно можно.
Все приложения есть в открытом доступе, можно зарегистрироваться и посмотреть что внутри до собеседования.
Для технической части собеседования не придумываем ничего заумного, а даём реальную задачу из проекта:
Есть экран веб-приложения. Перед кандидатом скриншот с уже реализованной функциональностью в системе.
Нужно описать REST API метод(-ы) для работы этого экрана.
👌 Тип метода GET выбирают правильно почти всегда.
👌 URL делают, не всегда так, как ожидаем. Но хотя бы понимаем, где придётся доучить.
🥲 А вот когда дело доходит до JSON, то тут мы можем смело принимать решение о продолжении диалога.
🔴 👉 Типичные ошибки и недочеты:
- Незнание типов данных.
- Дата и время - про стандарты ISO не слышали.
- Умение самостоятельно описать только "плоские" объекты данных, без вложенных структур.
- JSON запроса и ответа одинаковые, либо один из них теряется в случае методов, отличных от GET.
- Неумение работать со списками - массивы.
- Нейминг (именование полей) порой заставляет и смеяться, и плакать.
- Отсутствие знаний базовых структур для методов.
+ Незнание инструментов, что сразу показывает отсутствие опыта.
Это самое-самое, что бросается в глаза с первых минут. Давайте не будем допускать их? 🙂
Руководство по JSON, прикрепленный к посту - ваш будущий помощник и ориентир в проектировании API 📘
В нем собрала самое ключевое, чтобы не валить ваши собеседования и качественно выполнять свою работу 🙌
-----
P.S.
И большой намек к этому посту:
-----
Запоминаем, сохраняем, пользуемся 🙏
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥51❤13👍5❤🔥4
[GetAnalyst] RentACar Project - JSON GET _car_carId.json
1.1 KB
🔷 Пример задачи на проектировани JSON без списков 🔷
По мотивам предыдущего поста про JSON, показываю вам пример задачи, которую можно встретить в ходе собеседований на системного аналитика.
А также в реальной работе, когда вам приносят макет UI от дизайнера, и вы пониммаете, что половины данных в БД нет 😁 А дизайнеры и маркетологи уже придумали…
На скриншоте к посту мы видим экран приложения #RentACar. Он отображается пользователям веб-приложения после поиска авто, перед бронированием.
Метод REST API 👇
🔷 Запрос:
GET https://rentacar-project.com/api/public/v1/cars/{carId}
{carId} - идентификатор автомобиля в БД, path-параметр.
Пример запроса
GET https://rentacar-project.com/api/public/v1/cars/123
🔷 Успешный ответ:
HTTP-200
Тело ответа (пример):
На картинке к посту + в файле JSON.
Пояснения к процессу создания JSON в следуюшем посте 👇
#RestApiGA
По мотивам предыдущего поста про JSON, показываю вам пример задачи, которую можно встретить в ходе собеседований на системного аналитика.
А также в реальной работе, когда вам приносят макет UI от дизайнера, и вы пониммаете, что половины данных в БД нет 😁 А дизайнеры и маркетологи уже придумали…
На скриншоте к посту мы видим экран приложения #RentACar. Он отображается пользователям веб-приложения после поиска авто, перед бронированием.
Метод REST API 👇
🔷 Запрос:
GET https://rentacar-project.com/api/public/v1/cars/{carId}
{carId} - идентификатор автомобиля в БД, path-параметр.
Пример запроса
GET https://rentacar-project.com/api/public/v1/cars/123
🔷 Успешный ответ:
HTTP-200
Тело ответа (пример):
На картинке к посту + в файле JSON.
Пояснения к процессу создания JSON в следуюшем посте 👇
#RestApiGA
❤15👍7👏4