Comments 8
Много капитанства, по идее это очевидные шаги для многих кто хоть раз проектировал API(или писал без проектирования).
Кстати автор не написал о odata который как мне кажется решает кучу проблем для разработчиков больших систем с сущностями с кучей зависимостей.
Кстати автор не написал о odata который как мне кажется решает кучу проблем для разработчиков больших систем с сущностями с кучей зависимостей.
Может и капитанство, если вы эксперт и уже собаку съели на этом. Однако статья полезна привлечением внимания к теме формализованности подхода против стихийности. Интуитивно многие вещи может быть и понятны, особенно для людей с высоким уровнем самоорганизации, но какие-то шаги могут быть неявными. Да, обзор общий, но это ли не повод найти и просмотреть отдельные главы книги более детально? ;)
Еще полезными являются множества ссылок на ресурсы сгруппированные по решаемым задачам на каждом этапе.
Ваш комментарий уже выполняет задачи более глубокого уровня — поднять дискуссию, что могло быть упущено. Может какие-то протоколы сложнее, или легче для определенных задач, неважно какой пункт будет обсуждаться, главное увидеть мнения и опыт.
Еще полезными являются множества ссылок на ресурсы сгруппированные по решаемым задачам на каждом этапе.
Ваш комментарий уже выполняет задачи более глубокого уровня — поднять дискуссию, что могло быть упущено. Может какие-то протоколы сложнее, или легче для определенных задач, неважно какой пункт будет обсуждаться, главное увидеть мнения и опыт.
поддержу, сколько можно мусолить тему? Все равно бестолку, большинство крупных вендоров кладут на эти принципы (
У большинства вендоров легаси код с доисторических времен возможно. Однако если вы причастны к разработке публичных интерфейсов, то можно делать мир немного лучше в отдельно взятой эпсилон-окретсности своих клиентов.
Постоянные повторы и возвращения дискуссии могут помочь преодолеть так называемый «technology gap» значительно быстрее, на мой взгляд.
Постоянные повторы и возвращения дискуссии могут помочь преодолеть так называемый «technology gap» значительно быстрее, на мой взгляд.
Кладут не абстрактные вендоры, а конечные люди, принимающие решения — архитекторы, программисты и их менеджеры. Велика вероятность того, что никто из них не читал ничего на эту «замусоленную» тему, или читал, но не понял, не проникся, или читал, понял, проникся, но не смог объяснить начальству почему на это надо тратить время.
Отличная статья, но я огорчён тем что в ней нет даже попытки представить проектирование API как полностью идемпотентной системы — и соответственно, полностью иммутабельных данных.
Например, в идемпотентной системе не будет операции Edit Item — вместо неё будет каждый раз Create Item с новой версией содержимого. Тем самым мы «из коробки» получили бы историю версий (черновиков) документа, возврат к любой из них, статистику и т.д., и убрали бы риск ошибочной перезаписи документа. // Если кому-то это кажется экзотикой — знайте, что банальный Wordpress ведёт себя именно так.
В идемпотентной системе Status был бы не атрибутом документа, а отдельной сущностью, по которой предоставлялся бы отдельный «коробочный» CRUD-интерфейс (и далее либо document has status_id, либо status has document_id). Этот подход:
— решил бы задачи однозначности состояния документа (перевод в статус возможен только однократно, даже если кто-то по ошибке пошлёт несколько запросов),
— предоставил бы возможность указывать статусы для разных версий (черновиков) документов,
— возможность гибкого разграничения прав доступа для клиентов API (кто-то может только редактировать документ, а кто-то другой может задавать его статус),
— и «из коробки» дал бы возможность сохранять timestamp перехода в тот или иной статус.
То есть уже на втором пункте авторы вместо «придумайте сущность для каждого состояния» сразу идут по пути неиммутабельной системы, что уже неправильно.
Например, в идемпотентной системе не будет операции Edit Item — вместо неё будет каждый раз Create Item с новой версией содержимого. Тем самым мы «из коробки» получили бы историю версий (черновиков) документа, возврат к любой из них, статистику и т.д., и убрали бы риск ошибочной перезаписи документа. // Если кому-то это кажется экзотикой — знайте, что банальный Wordpress ведёт себя именно так.
В идемпотентной системе Status был бы не атрибутом документа, а отдельной сущностью, по которой предоставлялся бы отдельный «коробочный» CRUD-интерфейс (и далее либо document has status_id, либо status has document_id). Этот подход:
— решил бы задачи однозначности состояния документа (перевод в статус возможен только однократно, даже если кто-то по ошибке пошлёт несколько запросов),
— предоставил бы возможность указывать статусы для разных версий (черновиков) документов,
— возможность гибкого разграничения прав доступа для клиентов API (кто-то может только редактировать документ, а кто-то другой может задавать его статус),
— и «из коробки» дал бы возможность сохранять timestamp перехода в тот или иной статус.
То есть уже на втором пункте авторы вместо «придумайте сущность для каждого состояния» сразу идут по пути неиммутабельной системы, что уже неправильно.
Вы все правильно говорите про плюсы идемпотентной системы, но тут суть несколько в ином, как мне кажется. API в любом из смыслов (Web, public contract, другие) должен инкапсулировать детали реализации. В статье не форсируется реализации в соответствии с точными терминами в общеупотребительном смысле. Т.е. то же редактирование элемента — это бизнес-термин, понятный бизнесу и пользователю, а вы внутри можете это реализовать как угодно, разве нет?
Я полностью за немутабельные/замораживаемые объекты, так как с ними сильно проще работать. Но построение публичного интерфейса должно строиться с использованием «общего» (ubiquitous) языка для разработчиков и аналитиков/пользователей.
Я полностью за немутабельные/замораживаемые объекты, так как с ними сильно проще работать. Но построение публичного интерфейса должно строиться с использованием «общего» (ubiquitous) языка для разработчиков и аналитиков/пользователей.
Что и в каком формате должен отдавать метод OPTIONS?
Sign up to leave a comment.
Проектирование Web API в 7 шагов