JWT

유저의 권한이 있어야하는 기능들은 HTTP 통신 시 headers에 Authorization의 정보에 담겨서 통신하게 되고, 그 값은 보통 Token값이 된다. 백엔드에서는 Token값을 체크하고 그 안에 Payload에 담긴 유저정보를 확인해서 해당 Token이 내 서비스의 유저임을 파악할 수 있다. (JWT Validation)

Path Parameter

update 및 delete 시에는 Path Parameter를 이용하여 정보를 주고 받는 것이 RESTful한 API가 된다.

로직 구현 시 작성해볼 것

예를 들어 Service 로직을 구현할 때 좋은 팁
1. 로직 함수의 목적 - 로그인, 회원가입, 게시글 등록 등 목적을 파악한다.
2. input - DB에 저장하기 위해서는 input 값이 존재해야하고, 그 input값을 확인해서 받은 데이터가 필요하다.
3. 주요 로직 - 데이터를 가공하는 과정을 거치는 로직을 어떻게 짤 것인지 고민해야한다.
4. output - 데이터를 가공하여 dao를 거쳐 저장하고 가공한 데이터를 가지고 프론트엔드에 보내줄 수 잇는 output에 대한 고민이 필요.

정규표현식 (보통 Validation)

정규표현식 리터럴은 // 사이에 넣어서 사용 가능.
또한, 고정된 값이기 때문에 변수에 담을 때 변수명을 대문자로 사용하는 경우가 일반적임.

Query Parameter

100만개의 요소가 담긴 배열데이터를 한 번에 불러오는 것은 클라이언트 또는 서버에 굉장한 무리가 갈 수 있다. 이 때 Query Parameter를 이용해서 limit과 offset를 정의해주면서 방대한 배열을 잘라서 데이터를 가공할 수 있다.
limit : 불러올 요소의 갯수
offset : 불러올 시작점
ex) 127.0.0.1:8000/posts/all?offset=0&limit=100
모든 posts를 가져오는 엔드포인트의 뒤에 ? 부터 시작하는 Query Parameter를 달아준 형태이고,
offset=0은 0번째 요소부터 limit=100이니 100개씩 불러오겠다는 정보로 받아들일 수 있고
쿼리문 사용 시 SELECT * FROM posts LIMIT = 100 OFFSET = 0 의 형식으로 사용 가능하다.

데이터 유효성 검사

데이터를 받았을 때 그 데이터에 대한 유효성 검사 및 로직들이 이루어져야 하는 점을 잊지 않는 것이 프로젝트 흐름에 중요하게 작용 할 것이라고 생각함.