Rest API против GraphQL — идемпотент

Идемпотентность против кэширования

Прежде всего, кэширование и идемпотентность — разные вещи и не обязательно связаны друг с другом. Кэширование может использоваться или не использоваться для реализации идемпотентных операций — это, конечно, не обязательное требование.

Во-вторых, говоря о HTTP-запросах, идемпотентность в основном касается состояния сервера, а не его ответов. Идемпотентная операция оставит сервер в одном и том же состоянии, если будет выполняться несколько раз. Это не означает, что ответы, возвращаемые идемпотентной операцией, будут одинаковыми (хотя часто они могут быть такими).

Запросы GET в REST ожидаются идемпотентными по контракту, т. е. операция GET не должна иметь каких-либо побочных эффектов, изменяющих состояние на сервере (технически это может быть не всегда так, но ради объяснение давайте предположим, что это). Это не означает, что если вы ПОЛУЧИТЕ один и тот же ресурс несколько раз, вы всегда получите одни и те же данные. На самом деле, это не имеет смысла, поскольку ресурсы со временем меняются и могут быть удалены, верно? Таким образом, кэширование ответов GET может повысить производительность, но не имеет ничего общего с идемпотентностью.

С другой стороны, вы запрашиваете ресурс, а не произвольные данные. Запрос GET является идемпотентным в том смысле, что вы всегда будете получать один и тот же ресурс и никоим образом не будете изменять состояние системы.

Наконец, плохо (как ни странно?) разработанная операция GET на стороне сервера может иметь побочные эффекты, которые нарушат контракт REST и сделают операцию неидемпотентной. Простое кэширование ответов в таком случае не поможет.

ГрафQL

Мне нравится рассматривать запросы GraphQL как эквивалент GET в REST. Это означает, что если вы запрашиваете данные в GraphQL, распознаватели не должны не выполнять какие-либо побочные эффекты. Это гарантирует, что выполнение одного и того же запроса несколько раз оставит сервер в неизменном состоянии.

Так же, как и в простом GET, вы будете запрашивать определенные ресурсы, хотя, в отличие от GET, GraphQL позволяет запрашивать множество экземпляров ресурсов разных типов одновременно. Опять же, это не означает идентичных ответов, в первую очередь потому, что ресурсы могут меняться со временем.

Если некоторые из ваших запросов имеют побочные эффекты (например, они изменяют состояние ресурсов на сервере), они не являются идемпотентными! Вероятно, вам следует использовать мутации вместо запросов для достижения этих побочных эффектов. Использование мутаций дало бы понять клиенту/потребителю, что операция не является идемпотентной и должна обрабатываться соответствующим образом (входные данные мутации могут принимать ключи идемпотентности для обеспечения идемпотентности, подобной Stripe, но это отдельная тема).

Кэширование ответов GraphQL

Я надеюсь, что к настоящему моменту стало ясно, что кэширование не требуется для обеспечения/не того, что определяет идемпотентность запросов GraphQL. Он используется только для повышения производительности.

Если вас все еще интересуют варианты кэширования на стороне сервера для GraphQL, существует множество ресурсов. Вы можете начать с чтения того, что говорится в документации по серверу Apollo. тема. Не забывайте, что вы также можете кэшировать базу данных/сервис/и т.д. ответы. Я не собираюсь давать какие-либо конкретные предложения, поскольку, судя по вашему вопросу, в другом месте гораздо большая путаница.