API 설계
회원용 vs 비회원용 API
일반적으로 모든 서비스에는 회원용, 비회원용 API로 나뉘는데
대표적으로 비회원용 API에는 로그인, 회원가입이 있다.
우리는 회원용 API를 구현하기 위해 로그인을 통해 사용자를 체크하는 과정이 필수적이다. 로그인을 예로 들어보자.
LogIn
| Client |----------------------------| Server |
로그인을 위해 { ID, PWD } 전송 --->
기본적으로 HTTP와 HTTPS는 statleless이기 때문에
따로 절차를 취하지 않는 이상 모든 API 수행 시 로그인을 해야하는 단점이 생긴다.
1. 해결방법 1
그냥 전송할 때마다 정보를 전달해주자..!
- Request 시 Header에 ID, PWD를 넣어주어 인증과 동시에 API를 수행한다.
-> 단점: Packet이 해킹범으로부터 탈취를 당할 시 문제가 커진다..
2. 해결방법 2
놀이공원 자유이용권처럼 인증권을 받아 사용하자..!
| Client |---------------------------------------------------------| Server |
Cookie저장소 -------------------------------------------------Session 저장소
1. | Login 요청 | ---------------------------------------------------->
2. <------------------------------------------------------------| sessionID 전송 |
3. | 받은 sessionID를 Cookie저장소에 저장 | ----------------------
4. | LogIn 2회차 이후 요청 시 API에 sessionId 추가 전송 (header에 sessionID 저장)-->
-> 단점 1. 탈취의 위험성이 크다. (해킹범으로부터 탈취 당하면..)
-> 단점 2. 세션 과부하 문제 (서버가 저장소 운영에 신경 써야 함)
3. 해결방법 3
Big-5 Tech 사들의 기법으로 일부권한만을 허용하자..!
OAUTH 2.0 방식
| Client |------------------------------------------------------------------| Server |
1. | client가 ID, PWD와 함께 permission List를 전송함 | --------------------------------------->
2. <--------------------------------------------------| Server가 refresh Token을 client에게 전송 |
ㄴ 유효기간이 꽤 긴 1차 토큰
3. | client가 받은 refresh Token을 Server에게 전송 | ------------------------------------------->
4. <------------------------------------------------------------| Access Token을 client에게 전송 |
ㄴ 유효기간이 상대적으로 더 짧은 2차 토큰
5. | Aceess Token과 API를 동시에 보냄 | -------------------------------------------------------->
<장점>으로 보안성이 매우 좋다!
<단점>으로 구현 절차가 복잡하고 리소스 사용이 매우 많다.
4. 해결방법 4
JWT 방식 (Json Web Token) 방식을 통해 즉석 발권 방식을 통해 해결하자..!
| Client |------------------------------------------------------------------| Server |
1. | client가 ID, PWD 전송함 | ------------------------------------------------------------------>
2. <-------------------------------------------------------------| Server가 JWT를 Client에게 전송|
3. | client가 해당 JWT를 client용 저장소에 저장 (JWT를 계속저장) |
4. | 이후 API 수행 시 JWT를 헤더에 넣어 API 수행 | ------------------------------------------>
- Server는 저장소를 운영하지 않는 방식 (Backend Language 내 메소드로 확인)
- JWT는 로그인할 때마다 새로 발급 받는 방식이다. (유효 기간 지날 시 새로 로그인하여 재발급 받음)
JWT를 간단히알아보기
JWT의 3대 구성요소
- Header
- 토큰타입, 인코딩 방식
- Payload
- 데이터, 인코딩 방식
- 일반 vs 관리자용 구별용 데이터 등 데이터를 Payload에 실어 전송
- 하지만 탈취의 가능성이 있어 치명적 Data는 넣지 않는 것이 좋음
- Signature
- 어떤 서버에서 발급했는지 확인 가능한 자료
- Header와 Payload를 합친 것으로 Hash 기법을 통해 값을 도출한다.
-> 이러한 JWT는 전송 간에 Header에 첨부되어 이동한다.
-> 장점: 저장소가 따로 필요 없다.
-> 단점: Header에 첨부되어 이동하기 때문에 Header가 무거워짐.
cf) userId를 path-variable로 받아들여 사용되는 데이터와
Jwt를 통해 도출된 기존 userId를 비교하는 과정은 필수적이지 않다!
Restful한 방식에서는 점검해주는 게 좋으나 필수적이진 않음.
cf2) 일반적인 대형 포털사이트(naver 등)에서 PWD 관리
-> 비밀번호 생성 알고리즘에 있어 복호화 작업은 제공해주지 않는다. (단방향 Algo)
비밀번호를 잃어버릴 때 찾지 않고 새로 발급하는 이유이다.
소셜 로그인 및 인앱 결제 절차
- 사진으로 대체.. 추후 상세 절차 알아볼 것!
- ID, PWD를 client에서 제3자 서버(이후 카카오서버로 가정)에 전송
- 카카오 서버가 확인 후 Access Token을 client에게 전송
- Client가 받은 Access Token을 서비스를 받으려는 서버(이후 내 서버로 가정) 에 전송
- 내 서버가 카카오 서버에 Token의 유효성 검사를 위해 전송
- 카카오 서버가 확인후 관련한 응답 (내 서버에 필요한 data, ex. 유저 정보)을 전송
- 내 서버에서 받은 유저 정보를 내 DB에 전송
- DB에서 해당 데이터에 따른 정보를 응답
1. Client가 제 3자 서버(이후 카카오페이로 가정)에 결제를 요청
(( 돈이 부족한 경우
1-2-a. 페이머니를 카드사에 충전 요청
1-2-b. 카드사에서 카카오페이에 해당 액수만큼 충전 이후 응답))
2. 카카오페이에서 Client에게 결제한 영수증을 전송
3. Client가 받은 영수증을 서비스를 받으려는 서버(이후 배민 서버로 가정)에 영수증을 증거로 결제 이력 제출
4. 배민 서버 측에서 카카오 페이 측에 해당 영수증이 유효한 지 검사 요청
5. 카카오 페이 서버에서 확인 후 응답
6. 배민 서버 측에서 배민 DB에 해당 데이터 저장
7. 배민 DB에서 해당 데이터 관련한 응답
깔끔한 사진은 아래를 참고하길 바란다.
Transaction
한 번에 모두 처리해야할 하나의 작업 단위
트랜잭션 특징 ACID
Atomicity(원자성)
모든 작업이 반영되거나 모두 롤백되는 특성입니다
Consistency(일관성)
데이터는 미리 정의된 규칙에서만 수정이 가능한 특성을 의미합니다. 숫자컬럼에 문자열값을 저장이 안되도록 보장해줍니다.
Isolation(고립성)
A와 B 두개의 트랜젝션이 실행되고 있을 때, A의 작업들이 B에게 보여지는 정도를 의미합니다.
Durability(영구성)
한번 반영(커밋)된 트랜젝션의 내용은 영원히 적용되는 특성을 의미합니다.
이러한 점을 고민하여 Commit 및 RollBack을 해주어야 함.
ex) 쿼리문 2개의 동시 처리 등의 경우 특히나 구현 필요
ㄴ 은행 금융 결제 등
(A가 B에게 송금 시 A의 계좌에서 돈이 빠지는 것과 B의 계좌에 돈이 들어오는 행위가 동시에 이루어져야 함.)
