1. Paging
페이징 예시1)

각 페이지별로 정해진 양의 데이터를 보여주는 것
데이터 양을 잘라서 출력해주는 것
페이징 예시2 : 유튜브의 무한 스크롤 (어느 순간 reload되는 순간이 존재함)
페이징은 mysql에서 처리함 -> limit


limit 3 - 데이터 3개만 보여줌

limit 0,5 - 0번째부터 4번째 데이터까지 보여줌

페이지 번호마다 시작 인덱스의 번호, 즉 offset이 달라지고 있음
페이지 번호 = 1 -> 시작 인덱스 = 0
페이지 번호 = 2 -> 시작 인덱스 = 5
x = 페이지 번호, y = 시작 인덱스라고 하면 y=5x-5와 같은 함수가 만들어진다.
즉, limit pageSixe(page - 1), pageSize로 표현 가능하다.
pageSize와 page의 값은 쿼리스트링으로 받아오면 됨.
2. Transaction
송금을 예시로 들어보겠다.
A가 B한테 만원을 송금했다. 그럼 A에게서는 만원이 출금, B에게는 만원이 입금되어야햔다. 그런데.. B에게 입금되는 도중에 은행서비스에 에러가 생기게 되어 입금이 되지 않았다면.. A의 돈은 공중으로 사라져 버린 것 이다. 은행은 이런 경우 어떻게 처리할까? 은행은 송금 자체(출금+입금)를 하나의 거래로 본다. A의 돈이 B에게 입금 된 것이 확인 되어야 거래를 성사시킨다. 위와 같은 일이 벌어진다면 이 거래를 모두 취소하는 것이다. -> A의 돈도 사라지지 않고, 다시 송금을 할 수 있음
데이터베이스도 마찬가지로 각 작업들이 완료되어야 최종적으로 데이터베이스에 적용을 시켜야한다. 예를 들어 인스타그램 게시물 생성 API를 보면 다음과 같다.

여기서 게시물 생성은 되었는데, 게시물 사진에서 DB 오류가 발생했다고 해보자.
그럼 DB는 트랜잭션 명령어를 사용하여 지금까지의 작업이 이루어지지 않은 상태로 되돌린다.

데이터베이스에서는 처리한 과정들이 모두 성공했을 때만 최종적으로 DB에 반영하는 것이다.
이때 반영을 하는 명령어가 commit, 원상태로 되돌리는 명령어가 rollback이다.
3. 로그인

클라이언트가 서버에게 id, pwd를 전달하면 서버가 데이터베이스에서 그것들이 유효한지 확인 후, 그리고 유효하면 로그인을 해준다.
http는 stateless 특성을 가지고 있다. -> 상태를 저장하지 않음 -> 로그인을 해도 계속 유지되지 않음
# 로그인 유지 방식
1) 쿠키와 세션

세션은 서버의 스토리지
쿠키는 클라이언트의 스토리지
장점 : 구현이 간단함
단점 : 세션 ID가 노출되면 보안이 매우 취약함
2) jwt

클라이언트가 id, pwd를 서버에 보내고 유효하면 이 정보들을 바탕으로 jwt를 만들어서 클라이언트에게 보낸다. 그러면 클라이언트는 jwt를 헤더에 넣어서 회원용 api를 호출할 수 있게 된다.
클라이언트가 서버에 접속을 하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 '토큰'을 부여한다.
이 토큰은 유일하며 토큰을 발급받은 클라이언트는 또 다시 서버에 요청을 보낼 때 요청 헤더에 토큰을 심어서 보낸다.
그럼 서버에서는 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰과의 일치 여부를 체크하여 인증 과정을 처리하게 된다.

jwt는 payload, 헤더, 시그니처로 이루어져 있음
헤더 : 인코딩 방식
payload : 사용자의 정보, private하지 않은 값 (ex. userIdx)
시그니처 : payload, 헤더 암호화한 값
장점 : 리소스가 적게 필요함
단점 : 보안에 취약해 https가 필수
[WEB] 📚 JWT(Json Web Token )란? 💯 이해하기 쉽게 정리
Cookie & Session JWT 토큰을 배우기 앞서 쿠키와 세션에 대한 개념이 있으면, 토큰이 왜 사용이 되는지 ..등 보다 명확히 이해가 될수 있을 것이다. JWT를 배우기 앞서 우선 쿠키와 세션의 통신 방식을
inpa.tistory.com
3) OAuth
쉽게 설명하자면 놀이공원 big 5 이용권이다. 자유이용권과 달리 내가 원하는 놀이기구 5개를 탈 수 잇음.
이와 유사하다. 모든 권한을 주기에는 위험성이 있기에 한정된 권한을 주는 것이다. (ex.소셜 로그인)
장점 : 보안이 좋음
단점 : 로직이 복잡함
# 프로젝트 TIP

로컬에서 개발하고 dev서버에 완성된 api를 배포한다. 모든 api가 완성되고 test까지 완성되었다면 prod서버에 배포해준다.

RDS도 똑같이 dev RDS, prod RDS로 구분
으악 시간이 넘 빠르다... 10주차가 끝이라니 ㅠㅡㅠ
'Server > UMC 2기 Server' 카테고리의 다른 글
[UMC] Server 10주차 *실습* 로그인 API / JWT 발급 / 회원용 API 인증 (0) | 2022.05.27 |
---|---|
[UMC] Server 9주차 *POST*PATCH*DELETE* 게시물 생성 API / 게시물 수정 API / 게시물 삭제 API (0) | 2022.05.18 |
[UMC] Server 8주차 **GET** 유저 피드 조회 API / 게시물 리스트 조회 API (0) | 2022.05.12 |
[UMC] Server 7주차 유저 삭제 API (0) | 2022.05.07 |
[UMC] Server 7주차 Springboot / 유저 조회 API / API 명세서 작성 (0) | 2022.05.05 |
1. Paging
페이징 예시1)

각 페이지별로 정해진 양의 데이터를 보여주는 것
데이터 양을 잘라서 출력해주는 것
페이징 예시2 : 유튜브의 무한 스크롤 (어느 순간 reload되는 순간이 존재함)
페이징은 mysql에서 처리함 -> limit


limit 3 - 데이터 3개만 보여줌

limit 0,5 - 0번째부터 4번째 데이터까지 보여줌

페이지 번호마다 시작 인덱스의 번호, 즉 offset이 달라지고 있음
페이지 번호 = 1 -> 시작 인덱스 = 0
페이지 번호 = 2 -> 시작 인덱스 = 5
x = 페이지 번호, y = 시작 인덱스라고 하면 y=5x-5와 같은 함수가 만들어진다.
즉, limit pageSixe(page - 1), pageSize로 표현 가능하다.
pageSize와 page의 값은 쿼리스트링으로 받아오면 됨.
2. Transaction
송금을 예시로 들어보겠다.
A가 B한테 만원을 송금했다. 그럼 A에게서는 만원이 출금, B에게는 만원이 입금되어야햔다. 그런데.. B에게 입금되는 도중에 은행서비스에 에러가 생기게 되어 입금이 되지 않았다면.. A의 돈은 공중으로 사라져 버린 것 이다. 은행은 이런 경우 어떻게 처리할까? 은행은 송금 자체(출금+입금)를 하나의 거래로 본다. A의 돈이 B에게 입금 된 것이 확인 되어야 거래를 성사시킨다. 위와 같은 일이 벌어진다면 이 거래를 모두 취소하는 것이다. -> A의 돈도 사라지지 않고, 다시 송금을 할 수 있음
데이터베이스도 마찬가지로 각 작업들이 완료되어야 최종적으로 데이터베이스에 적용을 시켜야한다. 예를 들어 인스타그램 게시물 생성 API를 보면 다음과 같다.

여기서 게시물 생성은 되었는데, 게시물 사진에서 DB 오류가 발생했다고 해보자.
그럼 DB는 트랜잭션 명령어를 사용하여 지금까지의 작업이 이루어지지 않은 상태로 되돌린다.

데이터베이스에서는 처리한 과정들이 모두 성공했을 때만 최종적으로 DB에 반영하는 것이다.
이때 반영을 하는 명령어가 commit, 원상태로 되돌리는 명령어가 rollback이다.
3. 로그인

클라이언트가 서버에게 id, pwd를 전달하면 서버가 데이터베이스에서 그것들이 유효한지 확인 후, 그리고 유효하면 로그인을 해준다.
http는 stateless 특성을 가지고 있다. -> 상태를 저장하지 않음 -> 로그인을 해도 계속 유지되지 않음
# 로그인 유지 방식
1) 쿠키와 세션

세션은 서버의 스토리지
쿠키는 클라이언트의 스토리지
장점 : 구현이 간단함
단점 : 세션 ID가 노출되면 보안이 매우 취약함
2) jwt

클라이언트가 id, pwd를 서버에 보내고 유효하면 이 정보들을 바탕으로 jwt를 만들어서 클라이언트에게 보낸다. 그러면 클라이언트는 jwt를 헤더에 넣어서 회원용 api를 호출할 수 있게 된다.
클라이언트가 서버에 접속을 하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 '토큰'을 부여한다.
이 토큰은 유일하며 토큰을 발급받은 클라이언트는 또 다시 서버에 요청을 보낼 때 요청 헤더에 토큰을 심어서 보낸다.
그럼 서버에서는 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰과의 일치 여부를 체크하여 인증 과정을 처리하게 된다.

jwt는 payload, 헤더, 시그니처로 이루어져 있음
헤더 : 인코딩 방식
payload : 사용자의 정보, private하지 않은 값 (ex. userIdx)
시그니처 : payload, 헤더 암호화한 값
장점 : 리소스가 적게 필요함
단점 : 보안에 취약해 https가 필수
[WEB] 📚 JWT(Json Web Token )란? 💯 이해하기 쉽게 정리
Cookie & Session JWT 토큰을 배우기 앞서 쿠키와 세션에 대한 개념이 있으면, 토큰이 왜 사용이 되는지 ..등 보다 명확히 이해가 될수 있을 것이다. JWT를 배우기 앞서 우선 쿠키와 세션의 통신 방식을
inpa.tistory.com
3) OAuth
쉽게 설명하자면 놀이공원 big 5 이용권이다. 자유이용권과 달리 내가 원하는 놀이기구 5개를 탈 수 잇음.
이와 유사하다. 모든 권한을 주기에는 위험성이 있기에 한정된 권한을 주는 것이다. (ex.소셜 로그인)
장점 : 보안이 좋음
단점 : 로직이 복잡함
# 프로젝트 TIP

로컬에서 개발하고 dev서버에 완성된 api를 배포한다. 모든 api가 완성되고 test까지 완성되었다면 prod서버에 배포해준다.

RDS도 똑같이 dev RDS, prod RDS로 구분
으악 시간이 넘 빠르다... 10주차가 끝이라니 ㅠㅡㅠ
'Server > UMC 2기 Server' 카테고리의 다른 글
[UMC] Server 10주차 *실습* 로그인 API / JWT 발급 / 회원용 API 인증 (0) | 2022.05.27 |
---|---|
[UMC] Server 9주차 *POST*PATCH*DELETE* 게시물 생성 API / 게시물 수정 API / 게시물 삭제 API (0) | 2022.05.18 |
[UMC] Server 8주차 **GET** 유저 피드 조회 API / 게시물 리스트 조회 API (0) | 2022.05.12 |
[UMC] Server 7주차 유저 삭제 API (0) | 2022.05.07 |
[UMC] Server 7주차 Springboot / 유저 조회 API / API 명세서 작성 (0) | 2022.05.05 |