2022-04-12-TIL

2022-04-12-TIL

Today I Learned

API 응답으로 code와 message를 보내는데 에러코드를 어떻게 분류할지에 대해서 팀원들과 논의하던 중에 그 필요성이나 실효성이 있는지 고민하게 되었다. 반대의 의견으로는 그냥 RuntimeException만 던지고 에러메시지만 적절히 적어두면 충분하며, 어차피 에러코드에 매핑되는 커스텀 예외를 일일이 작성하는게 잘 지켜지지 않는다는 의견이다. 이미 돌아가는 애플리케이션에서 예외가 발생한다는 것은 버그일 경우가 많고, 버그를 수정한 상황에서는 예외가 발생하지 않는게 맞다. 한 마디로 500에러가 터져서 애플리케이션이 멈추는 현상은 없어야한다. 그렇게 하려면 최대한 많은 Checked Exception을 심어놓고 예상못한 예외가 아닌 원인이 분명한 에러로 만들면 된다. 그러면 Sentry 같은 에러로그 모니터링 시스템을 굳이 뒤져볼 필요없게 된다. Sentry를 찾아보는 것은 예외가 아닌 버그만 해당해야한다.

Business Exception is Good or Bad

• https://reflectoring.io/business-exceptions/
• https://docs.uipath.com/orchestrator/docs/business-exception-vs-application-exception
• https://stackoverflow.com/questions/5378005/when-is-it-ok-to-use-exception-handling-for-business-logic
• https://softwareengineering.stackexchange.com/questions/432069/business-logic-error-handling-should-exceptions-really-be-avoided
• https://tecoble.techcourse.co.kr/post/2020-08-17-custom-exception/

Checked Exception vs Unchecked Exception

• https://rollbar.com/blog/how-to-handle-checked-unchecked-exceptions-in-java/#:~:text=Difference%20Between%20Checked%20and%20Unchecked%20Exceptions%20in%20Java,-To%20summarize%2C%20the&text=A%20runtime%20exception%20is%20a,recovered%20or%20re%2Dtried%20from.
• https://www.java67.com/2012/12/difference-between-runtimeexception-and-checked-exception.html
• https://www.geeksforgeeks.org/checked-vs-unchecked-exceptions-in-java/
• https://madplay.github.io/post/java-checked-unchecked-exceptions
• https://stackoverflow.com/questions/6115896/understanding-checked-vs-unchecked-exceptions-in-java
• https://www.baeldung.com/java-checked-unchecked-exceptions
• https://stackoverflow.com/questions/613954/the-case-against-checked-exceptions#:~:text=%22Checked%20exceptions%20are%20bad%20because,be%20presented%20to%20the%20user%22.
• https://phauer.com/2015/checked-exceptions-are-evil/
• https://www.infoworld.com/article/3142626/are-checked-exceptions-good-or-bad.html
• https://programming.guide/java/checked-exceptions-good-or-bad.html

Exception Handling in Java

• https://umbum.dev/896
• https://b-programmer.tistory.com/261
• https://www.nextree.co.kr/p3239/
• https://happyer16.tistory.com/entry/10-Exceptions-%EC%98%88%EC%99%B8-%EC%B2%98%EB%A6%AC-Effective-Java-3th
• https://dzone.com/articles/9-best-practices-to-handle-exceptions-in-java
• https://joont.tistory.com/157
• https://okky.kr/article/362305
• https://umbum.dev/896
• https://kumarashwinhubert.com/10-exception-handling-best-practices-in-csharp
• https://www.javacodegeeks.com/10-best-practices-to-handle-java-exceptions.html
• https://www.techtarget.com/searchsecurity/feature/Exception-handling-best-practices-call-for-secure-code-design
• https://howtodoinjava.com/best-practices/java-exception-handling-best-practices/
• https://medium.com/swlh/the-error-handling-done-right-d19ffca2656f
• https://stackify.com/best-practices-exceptions-java/
• https://docs.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions

Exception Handling in Spring Boot

• https://codingwell.tistory.com/64
• https://jeong-pro.tistory.com/195
• https://bloowhale.tistory.com/72

Error Codes in API Design

API를 설계할 때 응답으로 그냥 ResponseEntity를 사용하여 단순히 HTTP Status Code만 사용하는 것이 옳을까? 물론 상태코드만 잘 사용해도 웬만한 에러는 모두 표현이 가능하다. 하지만 서버의 에러로그를 뒤져보기 전까지 클라이언트 입장에서는 에러가 정확히 무슨 원인으로 발생하는 것인지 알기어렵다.

따라서 에러 코드와 상세한 에러 메시지를 통해 API 요청이 왜 실패했는지 클라이언트에게 보여주는게 좋다고 생각한다. 그렇게 하려면 단순히 ResponseEntity로 응답하는 것 보다는 커스텀 Reponse를 공통으로 정의해놓고 사용하는 것이 좋다.

카카오 API에서는 어느정도 도메인 별로 에러코드가 나누어지는 것 같다.

• https://developers.kakao.com/docs/latest/en/reference/rest-api-reference
• https://developers.kakao.com/docs/latest/en/kakaologin/trouble-shooting
• https://developers.kakaopay.com/docs/getting-started/basic/basic-errorcode

구글의 API는 코드를 따로 정의하지는 않고 해당 도메인과 원인을 응답에 포함한다.

• https://cloud.google.com/storage/docs/json_api/v1/status-codes
• https://cloud.google.com/apis/design/errors
• https://developers.google.com/search-ads/v2/standard-error-responses
• https://developers.google.com/calendar/api/v3/reference/calendarList#resource

페이스북은 코드, 하위코드, 메시지 제목과 내용까지 상세하게 표현한다.

• https://developers.facebook.com/docs/instagram-api/reference/error-codes/
• https://developers.facebook.com/docs/graph-api/guides/error-handling

네이버는 대체로 상태코드와 메시지로만 표현한다. 일부는 에러 코드를 별도로 관리하고 메시지를 포함해서 원인을 알기쉽게 해놓았다.

• https://developers.naver.com/docs/common/openapiguide/errorcode.md
• https://developers.naver.com/docs/clova/client/Develop/References/CIC_API.md#CICMessageFormat
• https://api.ncloud-docs.com/docs/common-ncpapi
• https://developers.naver.com/docs/clova/api/CFR/API_Guide.md#PHP
• https://api.ncloud-docs.com/docs/ai-naver-mapsdirections

NHN도 에러코드 네 자리와 타입, 설명이 포함된다. CAFE24도 마찬가지이다.

• https://docs.toast.com/ko/Mobile%20Service/IAP/ko/error-code/
• https://developers.cafe24.com/app/front/develop/api/errors

HTTP Status Code

• https://sanghaklee.tistory.com/61
• https://developer.mozilla.org/ko/docs/Web/HTTP/Status

Spring Boot ResponseEntity

• https://zetcode.com/springboot/responseentity/#:~:text=ResponseEntity%20represents%20an%20HTTP%20response,add%20headers%20and%20status%20code.
• https://hooongs.tistory.com/95
• https://stackoverflow.com/questions/22725143/what-is-the-difference-between-responseentityt-and-responsebody

REST API Design Best Practices

• https://www.partech.nl/nl/publicaties/2020/07/9-trending-best-practices-for-rest-api-development
• https://swagger.io/resources/articles/best-practices-in-api-design/
• https://www.freecodecamp.org/news/rest-api-best-practices-rest-endpoint-design-examples/
• https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design
• https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/
• https://hevodata.com/learn/rest-api-best-practices/
• https://www.toptal.com/api-developers/5-golden-rules-for-designing-a-great-web-api
• https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
• https://dev.to/lanars_inc/web-application-architecture-best-practices-and-guides-35ek
• https://www.altexsoft.com/blog/rest-api-design/
• https://www.acunetix.com/blog/web-security-zone/7-web-application-security-best-practices/

REST API Error Handling

• https://www.baeldung.com/rest-api-error-handling-best-practices
• https://nordicapis.com/best-practices-api-error-handling/
• https://pjh3749.tistory.com/273
• https://blog.restcase.com/rest-api-error-codes-101/
• https://www.outsystems.com/blog/posts/implementing-http-status-code-exposing-rest/
• https://code-maze.com/top-rest-api-best-practices/
• https://stackoverflow.com/questions/43602325/rest-api-http-status-code-best-practices
• https://stackify.com/web-api-error-handling/
• https://www.moesif.com/blog/technical/api-design/Which-HTTP-Status-Code-To-Use-For-Every-CRUD-App/
• http://lab.gamecodi.com/board/zboard.php?id=GAMECODILAB_QnA_etc&page=55&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=desc&no=3042