Rest API
이전에는 url 의 형태가 다양하고 데이터를 보내는 방법이 여러가지였음 -> 표준이 없어서 가독성이 떨어지고 유지보수가 어려움 -> API 표준을 정함 = Restful API
- Restful API
- 자원 단위로 설계된 API
- post 생성 get 조회 patch 일부 수정 delete 삭제 put 수정
- 장점
- 파일 확장자 노출 X
- 메소드가 직관적임
- 리소스 단위 설계 - 이게 어떤 API 이고 어떤 기능을 하는지 직관적으로 알 수 있음
ex1) userId 가 2 인 유저 정보 조회
GET /users/2 (path variable)
ex2) 회원가입
POST /users/ - body 에 데이터를 담아서 전송
ex3) userId 가 4 인 유저 정보를 수정
PATCH /users/ - body 에 데이터를 담아서 전송
- 정리
- 무엇을 변경하는가?
HTTP Method : 행위
무엇 : URI💡 URI에는 행위에 대한 내용이 들어가면 안 된다, HTTP Method 에 이미 포함되어 있기 때문
ex. GET /search/webtoon ❌
- 무엇을 변경하는가?
로그인 유지 방식
Q. 로그인은 왜 유지가 안 될까?
A. HTTP 는 비연결성과 무상태성을 띄고 있음 - 사용자의 요청을 처리하면 자원 낭비를 막기 위해 연결을 끊음, 로그인 유지 안 됨
- 쿠키-세션 방식 like 놀이공원 자유이용권
클라이언트가 서버에 로그인을 요청(body 로 정보 전달) -> 서버가 회원이 맞는지 검증 -> 서버에서는 세션으로 저장, 클라이언트에서는 쿠키로 저장(이 쿠키를 사용해 지속적으로 로그인 상태를 유지할 수 있음)- 장점
구현이 단순함 - 단점
기기에 정보가 계속 남아 있기 때문에 보안 취약
- 장점
- oAuth 방식 = 소셜 로그인 방식 like Big3 티켓
동의한 항목에 대해서만 권한, 허가만 줌
클라이언트가 소셜 로그인함 -> 해당 앱이 아닌 소셜 로그인 서버에 정보 전달 -> 인증을 받으면 소셜 로그인 서버에서 (RefreshToken -> )AccessToken 발급(해당 앱은 소셜 로그인 계정을 이용할 수 있는 권한만 받은 셈) -> 이 AccessToken 이 해당 앱 서버로 전달(POST body 로 해당 앱에 전달) -> 해당 앱에서 해당 앱을 사용할 수 있는 토큰 발급 -> 로그인 이용 가능
- RefreshToken & AccessToken
RefreshToken 유효기간 1달
AccessToken 유효기간 maybe 하루 미만
RefreshToken 이 유효하면 AccessToken 발급되는 방식
Q. 왜 이중으로 발급받는 구조일까?
A. 보안이 더 강화되기 때문이다
AccessToken 은 유효 기간이 짧기 때문에 탈취해도 사실상 사용 불가
RefreshToken 은 AccessToken 이 만료될 때마다 서버에서 전송해줌 - 언제 AccessToken 이 만료될지 모르므로 보안이 강화됨
- RefreshToken & AccessToken
- ⭐️ JWT(Json Web Token) - 매번 표 검사
header + payload + signature구조
header토큰 타입, 알고리즘 해시키
payload토큰의 내용(데이터) - 어떤 권한을 부여받았는지
signature암호화된 내용 - JWT 를 만든 사람만 해독키를 알고 있음
- 알아가기
header -> payload 는 base64 로 인코딩, 따로 암호화 하지는 않음
signature 는 base64 로 암호화된 header 와 payload 를 합쳐서 암호화키를 더함 - header 와 payload 가 변조된 것을 바로 알 수 있음 - 보안 강화
자동 로그인 = 사용자의 기기에 JWT 가 있는가를 확인
- 장점
보안이 강한 편이며 자원 낭비가 적음 - 단점
보안을 더 강화하려면 https 와 함께 사용해야 함
