Комментарии 6
Ясно изложено. Сразу видно что технический писатель писал. Но "v1" на картинке все же странный, для программистов, номер версии:)
Разве API пишется, а не проектируется?
Опять пошло обесценивание проектирования, как со словами «составить ТЗ» (ага, как кубики лего из уже готовых частей), «собрать требования» (да просто по углам пылесосом пройтись, уже ведь готовые требования лежат, да?)
Если это такая простая тема, непонятно, зачем целые книжки про design API пишут. Надо же просто техписа нанять и он по статье на хабре всё сделает)
Ох эти вечные споры между rest и graphql, жаль не увидел, что лучше, а то бы втянулся в батл :))
Как сейчас удобный софт под API aggregate gateway (объединение результатов из двух микросервисов) которые находятся в Кубернетес?
Есть несколько моментов, которые хотелось бы обсудить:
В статье рекомендуется использовать Rest или GraphQL, однако примеры включают методы GetList и GetCount. Было бы полезно уточнить, как они соотносятся с ресурсоориентированным подходом к проектированию Rest API, о котором говорится в предложенных ссылках.
В разделе "Советы по созданию удобного API" присутствует совет "Используйте кеширование". Было бы здорово, если бы были дополнительные разъяснения о том, как кеширование способствует удобству API.
В статье пронумеровано 9 пунктов, было бы наверное удобным добавить нумерацию ко всем 15 пунктам заявленным в заголовке.
В разделе "Напишите понятную документацию" представлен как пример текст документации, непонятный и не информативный, это субъективно :)
Почему пример с кешированием на python а в ссылках разработка на dotnet ?
Тема действительно актуальна и вызывает большой интерес, и я верю, что есть много возможностей для дальнейшего улучшения материала.
Как написать удобный API — 15 рекомендаций