REST API 디자인 설계

1. REST 개요

• REST 구성

REST 구성

• REST 기본

REST 기본

• REST의 특성
  • REST는 캐싱이 가능하다, 위의 예시처럼 Last-Modified에 따라 캐싱할 수 있음 / 그래서 CDN 활용 가능

REST의 특성

• REST 단점

REST 단점

• REST 안티 패턴
  • 동일한 URL 패턴 안에 서로 다른 기능을 하는 함수를 정의하는 것 → 가독성이 엄청 떨어짐

REST 안티 패턴

2. 설계 패턴

B 방법보단 A 방법을 많이 사용한다

디자인 시작하기 전에 미리 정하고 들어가는 것이 좋음

error body 형식은 위에 처럼, moreinfo는 오픈 API가 아닌 경우에는 제외해도 상관 없음

• error body에 콜스택을 넣는 것은 보안에 취약해짐
• error code는 넣어주어야 함. 왜냐하면 고객이 에러 코드를 가지고 검색할 수 있게 하기 위해서
• error code 정할 때 서비스 별로 range를 나누어서 정리하고 초기에는 1000, 1001, 1002 이런 것보단 1000, 1010, 1020 이런식으로 정하는 것이 좋다. 왜냐하면 나중에 하나의 에러에 비슷한 에러가 더 생길 수도 있기 때문에 이런 식으로 구성하면 좋다

3. API 보안

• REST API 보안은 크게 5가지로 접근해야 한다
  1. 인증 (Authentication)
  2. 인가 (Authorization)
  3. 네트워크 레벨 전송 암호화
  4. 메세지 무결성 보장
  5. 메시지 본문 암호화
• https://bcho.tistory.com/955

REST API의 이해와 설계-#3 API 보안

3-1. API 인증 (Authentication)

3-2. API 인가 (Authorization)

• 권한 처리는 클라이언트 단이나 API Gateway에서는 처리하기 힘들고, API Server 단에서 처리를 해주어야 한다
• 그래서 메서드 별로 어떤 유저만 실행할 수 있다 이런 식으로 코드를 구현하고 주석을 달아주어야 함 (아니면 스프링 security 사용)
• 물론 API Gateway를 통해서 권한마다 URL 자체를 통제하는 방법도 있긴 한데 좋은 방법은 아님. 진짜 단순한 /admin, /user 같은거는 API Gateway에서 처리해줘도 괜찮음

3-3. 네트워크 레벨 전송 암호화

• 중간자 공격 막는 방법 : 클라이언트 단에서 인증서 발급자를 확인하면 됨
  ex) 인터넷 하다보면 나오는 신뢰되지 않은 인증서 오류 페이지

3-4. 메세지 무결성 보장

• replay 공격을 막기 위해 해시 알고리즘을 사용하는 것, 메세지에 timestamp 또는 솔트값을 붙이고 해시 돌려서 보냄

3-5. 메시지 본문 암호화

• REST 평문을 보내기 전에 암호화를 해서 보내는 것
• 왜냐하면 SSL을 뚫고 들어오는 공격자가 존재하기 때문
• 속도가 느려지겠지만, 보안이 많이 중요한 프로젝트일 경우에는 그냥 쓰자 (생각보다 오래 안걸림)

4. JWT 토큰

• 변조 방지하는게 기본적으로 들어가 있음

https://jwt.io/

• https://jwt.io/libraries

JWT.IO

5. API 문서화