REST-API

REST 기반의 간단한 분산 트랜잭션 구현 -1편 TCC 개관 REST 기반의 간단한 분산 트랜잭션 구현 - 2편 TCC Cancel, Timeout REST 기반의 간단한 분산 트랜잭션 구현 - 3편 TCC Confirm(Eventual Consistency) REST 기반의 간단한 분산 트랜잭션 구현 - 4편 REST Retry 지난 글 에서는 TCC Try-Confirm/Cancel 에서 'Confirm 하기 전에 실패하는 경우' 일관성을 유지하기 위한 방법으로 Timeout과 Cancel을 이야기했다. 그리고  휴리스틱 예외를 언급하면서 결과적 일관성 모델을 간단하게 소개하였다. 이번 글은 결과적 일관성 모델을 사용하여 'TCC Confirm 중에 실패하는 경우' 일관성을 유지하는 방법에 대해 다룬다....

REST 기반의 간단한 분산 트랜잭션 구현 -1편 TCC 개관 REST 기반의 간단한 분산 트랜잭션 구현 - 2편 TCC Cancel, Timeout REST 기반의 간단한 분산 트랜잭션 구현 - 3편 TCC Confirm(Eventual Consistency) REST 기반의 간단한 분산 트랜잭션 구현 - 4편 REST Retry 안영회 님은 마이크로 서비스 공부하게 책 하나 추천해주세요 글에서 마이크로 서비스 간 일관성을 유지하는 방법 중 하나로 TCC Try-Confirm/Cancel 를 언급했다. How to become eventually consistent. 오호… 지옥(?)에 오신 것을 환영한다. 내 모듈에 처리된 내용이 다른 모듈과 일관성을 유지하려면 어떻게 해야 하나? 알려진 방법으로...

2달전 제 뒤에 앉아았는 개발자님께서 왜 알아보기 어렵게 날짜를 숫자로 사용해야하냐고 의문을 가진 적이 있다. API를 처음 구성할 때 참고했던 API가 사용했다는 이유로, spring 400에러 응답에서도 long 형태의 시간표현을 한 사례, Timezone과 DB처리에서 장점이 있다는 이유로 적용했던 Unix Time형태의 날짜 표현방식이 문제가 될 수도 있다는 생각이 들었다. 그렇게 불편하다면 한번 바꿔볼까? 하는 생각과 함께 고민을 시작했다. API 설계를 위해 REST에 대해 학습하는 과정에서 우리는 URI, Method, Http Status 에만 집중한다. 하지만 API를 개발하고 사용하는 목표는 결국 데이터를 주고 받는데 있기 때문에 데이터가 담기는 Parameter, Request/Response Body의 형태를 정하고 Interface로 약속해야 한다....

마이크로서비스 아키텍처는 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처를 말합니다. 애플리케이션을 특화된 기능별로 나누게 되면 자연스럽게 애플리케이션의 추상화(abstraction)가 가능해집니다. ...