문서의 선택한 두 판 사이의 차이를 보여줍니다.
양쪽 이전 판 이전 판 | 다음 판 양쪽 다음 판 | ||
web:신규서비스 [2022/02/08 21:48] kwon37xi |
web:신규서비스 [2022/02/10 10:38] kwon37xi [API 설계] |
||
---|---|---|---|
줄 379: | 줄 379: | ||
* API 호출 내부에서 다른 API를 호출해서 결과를 합치는 일을 하는 것은 좋지 않다. 내부 호출 API의 장애가 전체적으로 다 전파 돼 버린다. | * API 호출 내부에서 다른 API를 호출해서 결과를 합치는 일을 하는 것은 좋지 않다. 내부 호출 API의 장애가 전체적으로 다 전파 돼 버린다. | ||
* 최초의 API호출자는 여러 API 호출이 필요하면 다른 API에게 또 다른 API호출을 요청하기 보다는 스스로 모든 요청을 하는게 장애 포인트를 줄여나가는 방법이다. | * 최초의 API호출자는 여러 API 호출이 필요하면 다른 API에게 또 다른 API호출을 요청하기 보다는 스스로 모든 요청을 하는게 장애 포인트를 줄여나가는 방법이다. | ||
+ | * 오류를 오류를 발생시키는게 낫다. | ||
+ | * 오류 발생시 API 응답은 200 으로 정상으로 내리면서, | ||
+ | * 이렇게 되면 모든 호출자가 응답에 오류코드가 있는지 일일이 확인해야 한다. | ||
+ | * 이를 확인하지 않고 데이터를 사용할 경우 에러가 즉각 발생했으면 오히려 문제가 덜 발생했을 것을 더 큰 문제로 커지게 된다. | ||
+ | * 예를들어 에러코드는 존재하고, | ||
===== MQ 등을 통한 비동기 처리 ===== | ===== MQ 등을 통한 비동기 처리 ===== | ||
* 비동기 처리는 반응 속도를 높이고 전송 신뢰도를 높여주는 등 좋은 점이 있지만 단점들도 많으므로 확실히 이해해야 한다. | * 비동기 처리는 반응 속도를 높이고 전송 신뢰도를 높여주는 등 좋은 점이 있지만 단점들도 많으므로 확실히 이해해야 한다. |