ВоITи и выITи

Я недавно посмотрел курс Designing & Versioning HTTP/REST APIs от Jeffrey Richter , известнейшего автора таких основополагающих книг как CLR via C# и Windows API via C++ . Надеюсь, вы сталкивались с ними или даже читали их. Я рекомендую этот курс к просмотру, особенно тем, кто считает что дизайн API это легко (что-то вроде "перекладывания JSON'ов"). Однако, как и с многими другими курсами, просмотр такого материала не даёт нужного глубокого понимания вопросов. Даже с таким автором. Комбинирование практики с теорией обязательно в основоении любого материала, а тем более в применении его в условиях релиза Эта рекомендация относится к разработчикам любого уровня. Легко просмотреть курс и поставить новую галочку в резюме, однако "Дьявол кроется в деталях". Во время реальной разработки возникает множество вопросов, о которых не так просто вспомнить в момент обучения. Ну, довольно слов. Давайте рассмотрим конкретный пример, часть курса по теме Versioning

  Довольно просто полюбить новую технологию по проспектам профессиональных маркетологов. Но важно не попасть в ловушку, потому что в программировании не существует серебряной пули, решающей все проблемы разом. GraphQL находится в центре внимания уже пару лет. Прежде чем вы добавите эту красивую аббревиатуру в своё резюме, я хотел бы поделиться краткими выводами и мыслями, основанными на опыте использования GraphQL в продакшене. Недавно вышло обзорное видео от знаменитого Алекса Сюй (автора книг по системному дизайну), которое полезно посмотреть перед чтением дальше, так как я не хочу повторять все те вещи, о которых другие авторы сказали лучше.   Я подтверждаю всё, о чём сказано в видео, однако хотел бы добавить кое что, так как часто слышу от разработчиков ошибочные заявления. GraphQL не является заменой REST или SOAP Это просто еще один способ создать API немного по-другому, но определенно его нельзя считать «лучшим, потому что новый». Я бы даже сказал, что GraphQL больше схож с S