Сегодня мы провели интересную дискуссию о том, что должен делать наш API по умолчанию при проверке тела запроса, где присутствуют неожиданные поля. Я думаю, что мы закончили разговор в хорошем месте, но это поднимает некоторую мета-точку того, применять ли закон Постела или как его применить, и который я хотел бы изучить далее.
Наше приложение, по сути, представляет собой большую и сложную систему управления заказами, сопоставления и диспетчеризации (аналогичную сервису совместного использования). Большинство наших конечных точек связаны с действиями на различных этапах в потоках ввода, сопоставления и управления заказами, в дополнение к управлению объектами (CRUD). Мы не планируем публично открывать этот API, поэтому единственными клиентами являются наши мобильные и веб-приложения (и, возможно, скрипты, которые мы пишем).
В прошлом я писал системы, в которых мы использовали либеральный подход к принятию полей, где была ситуация, когда мы получали поток событий, с которым нам приходилось работать. В этом случае API должен быть либеральным в принятии произвольных полей, так как в противном случае вышестоящий производитель не сможет эффективно добавлять функции или изменять свою систему.
Однако в нашем случае мне кажется, что это тот случай, когда мы хотим быть строгими в том, что принимаем. Все пользователи здесь будут внутренними разработчиками, поэтому трудно представить себе множество распространенных ситуаций, когда вседозволенность дает вам надёжность по сравнению со строгим API. Мы согласились с тем, что есть значительные улучшения в разработке по сравнению со строгим API и множество ошибок, которых мы можем избежать, строго проверив во время разработки, однако есть аргументы в пользу того, что разрешающий API более надежен в prod, не подвергая бомбардировке другие приемлемые запросы. , Однако, поскольку мы контролируем все законные клиенты, похоже, что в этой ситуации мы не должны оказываться, за исключением некоторых редких случаев выпуска клиентов, которые используют некоторые поля, прежде чем API будет готов их использовать. Поэтому, если мы начнем видеть неожиданные поля, мы, по крайней мере, захотим знать и, скорее всего, ошибемся большую часть времени. Есть ли общий случай, когда мне не хватает того, где нас будет тормозить ограничительный API.
В команде есть некоторые отличия, поэтому некоторые из них могут быть вызваны разными взглядами. Я хотел бы услышать и понять мнения других здесь, так как я не в полной мере покупаю аргументы в пользу того, чтобы разрешить быть более надежным и нам, желающим обслуживать клиентов, у которых неожиданные поля.