Comments 2
Лишние бессмысленные слова в названиях ресурсов и полей. Названия
company_info,address_details,country_codeбудут выглядеть лучше, если вместо них использоватьcompany,address,country
Нет не будут
entity.country.code или entity.countryCode
В обоих случаях хотя бы примерно понятно о чем речь.
Лишних и бессмысленных слов в названии быть не может, иначе рано или поздно вы окажетесь в ситуации где у вас сущность на 200 полей, а вам нужно по каждому нырять в документацию, которая устарела. И в поле currency разом окажется $, RUB, руб и прочее.
PS у меня при прочтении статьи в голове не пропадало ощущение что пол дизайнера пропадет если перейти на JsonRPC а вторая если перейти вообще на GraphQL
Сущность в 200 полей с разнородными значениями + плохая документация — это как раз пример того, что случается, когда дизайн не определяется централизованно. Гайдлайны и линтеры как раз для того, чтобы поля назывались одинаково в разных сервисах и в них лежали всегда одинаковые значения.
Год от года рынок специалистов по дизайну и выпуску API растет и требует больше народу. Наладить выпуск и контроль качества в продукте, который, например, построен из 1000 микросервисов и все они должны одновременно показывать клиенту однородный и консистентый дизайн — это непростая задача. Причем с технологиями типа GraphQL тоже хватает мест, где накосячить (даже с теми же названиями и списками полей)
Как индикатор роста спроса на такого рода услуги выступают конференции вроде https://www.apidays.global/ — это уже 20-30 эвентов каждый год, на которых вырабатываются новые стандарты, решаются проблемы поддержки, запуска и тестирования публичных и приватных API интерфейсов. А хороший инженер по контролю за API сейчас стоит больше $100 000 в год
Почему API приложениям нужен дизайн гайдлайн: рассказываем, показываем и делимся своим