Блог

Небольшой вопрос относительно того, как отвечать на веб-запрос restful при наличии другой половины информации.

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

Сценарий: Некоторая клиентская служба SERVICE_A — это своего рода служба, позволяющая клиенту покупать продукты. Однако SERVICE_A знает только продукт. Это означает, что SERVICE_A не знает цену продукта, ему необходимо вызвать SERVICE_B, чтобы получить цену продукта в режиме реального времени. С учетом сказанного, SERVICE_A, знающий только половину информации, знает только продукт, а не цену продукта.

Клиент выберет продукт через интерфейс SERVICE_A. Клиент не может перейти к другим сервисам. Затем SERVICE_A вызовет SERVICE_B (1) с продуктом через API. что-то вроде :

 {
    "product": "someProduct"
}
  

Затем SERVICE_B получит запрос (2) и затем вычислит цену с помощью своего собственного алгоритма, который он знает (3).

После завершения SERVICE_B вернет цену SERVICE_A (4), у которого теперь есть вся информация, и он может отобразить ее клиенту.

• В точке (1) SERVICE_A знает только половину информации. Только продукт.

• В точке (2) SERVICE_B при получении запроса также знает только половину информации, только продукт.

• В точке (3) SERVICE_B впервые будет знать обе половины информации, продукт и цену!

• В точке (4) SERVICE_A, который получает ответ, также получит обе половины.

Мой вопрос в том, должен ли SERVICE_B отправлять только свою половину информации обратно в SERVICE_A и позволить SERVICE_A восстановить все целиком? Или отправлять обратно обе одновременно?

SERVICE_B отправляет обратно только цену. SERVICE_A, который отправляет запрос, реконструирует someProduct = 1.2

 {
    "price": 1.2
}
  

Или SERVICE_B должен отправлять обратно все.

 {
    "product": "someProduct",
    "price": 1.2
}
  

В моем примере я использую только одно поле. Но на самом деле их гораздо больше. Это всего лишь пример.

Опять же, это не вопрос мнения. Я считаю, что должен быть ответ, основанный на производительности, принципе проектирования, архитектуре микросервисов и т. Д.

Спасибо

Мой вопрос в том, должен ли SERVICE_B отправлять только свою половину информации обратно в SERVICE_A и позволить SERVICE_A восстановить все целиком? Или отправлять обратно обе одновременно?

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

 GET /price-list?product=someproduct
  

По сути, вы спрашиваете, должен ли продукт быть частью представления, на что я отвечаю:

• конечно, почему бы и нет?
• но вам и не нужно.

Если в URI есть «еще много» элементов, вы можете выбрать, какие из них вам нужны.

Может помочь просмотреть главу 5 диссертации Филдинга и, в частности, его замечания об ограничении кэша.

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

Другими словами, для информации, которая, по нашему мнению, будет медленно меняться, эффективность достигается за счет уменьшения количества обходов, а не за счет уменьшения размера ответа.

Таким образом, вы с большей вероятностью добавите дополнительную информацию в ответ (при условии, что время кэширования остается удовлетворительным).

Теперь, если вместо REST вы используете дизайн с большим количеством символов RPC (SOAP / GraphQL / gRPC), ответ может измениться, потому что «кэширование» теряет большую часть своей мощности, когда компоненты общего назначения не могут его использовать.

Если в любом случае будут дополнительные поездки туда и обратно, может иметь смысл уменьшить полезную нагрузку.

Лично я был бы склонен включать информацию, предоставленную клиентом, потому что это дает вам средства, с помощью которых вы можете устранять определенные виды ошибок. Но это позиция «при прочих равных условиях». Если вам нужен небольшой, если вам это действительно нужно, тогда вам нужно внимательно рассмотреть бюджет при внедрении поддержки устранения неполадок.