8월 셋째주 WIL겸 TIL
TIL 목록
- req.body 한번에 넘기기
- 탈퇴의 영어표현
- HTTP 메서드
일주일간 공부하며 느낀 점
참조한 페이지
1. req.body 한번에 넘기기
어제 알아낸 방법에서 주의할 점이 하나 있다는 점을 알게 되었다.
resignUser_service = async (token, deleteData) => {
try {
const { password } = deleteData;넘긴게 하나뿐이더라도 비구조화 할당을 하여야한다.
console.log('password :', typeof password, password로 값을 자세히보자.
만약 비구조화 할당을 하지 않는다면 다음과같이 object { password: '1q2w3e4' } object로 받게된다.
비구조화 할당을 한다면 password : string 1q2w3e4 string으로 받게된다.
아래와 같이 특정한 작업을 수행하때 type때문에 문제가 생길 수 있다.
const passwordMatch = await bcrypt.compare(password, user.password);2. 탈퇴의 영어표현
탈퇴 매서드를 만들어야하는데 탈퇴가 영어로 뭔지 알수가 없어서 검색을 했다.
Withdraw : 물리적인 탈퇴, 또는 현금 인출에 사용하는 표현
Resign : 공식적인 탈퇴 선언에 사용하는 표현
Quit : 일을 그만둠을 뜻하는 비격식적인 표현
Leave : 조직에서 떠나는 것을 뜻하는 범용적인 표현
Cancel : 멤버쉽등의 자격을 취소/박탈을 의미하는 표현
signin, signup과 비슷한 느낌인 resign을 선택하였다.
3. HTTP 메서드
내가 알고 있는 것
클라이언트와 서버간에서 요청(Request)과 응답(Response)을 주고 받을때 서버에서 해야할 동작을 지정해주는 것을 말한다.
주로 사용하는 매서드로는
POST : 데이터 생성하기
GET : 데이터 불러오기
PUT/PATCH : 데이터 업데이트하기
- PUT : 데이터 덮어씌우기(빈값 포함), 서버에 없는 컬럼을 요청시 새로 생성한다.
- PATCH : 요청을 보낸 데이터만 업데이트하기, 서버에 없는 컬럼을 요청시 서버에서 따로 예외 처리를 만들어야한다.
DELETE : 데이터 삭제하기
위의 네가지가 있다.
매서드 요청을 할때는 RESTful api라는 표준을 따르는 것이 일반적이다.
무상태(서버가 클라이언트의 상태를 기억하지 않는다.)와 확장성을 장점으로 가지는 방식이다.
추가로 검색하여 합친 것
클라이언트와 서버간에서 요청(Request)과 응답(Response)을 주고 받을때 서버에서 해야할 동작을 지정해주는 것을 말한다.
주로 사용하는 매서드로는
POST : 데이터 생성하기
GET : 데이터 불러오기
PUT/PATCH : 데이터 업데이트하기
- PUT : 데이터 덮어씌우기(빈값 포함), 서버에 없는 컬럼을 요청시 새로 생성한다.
- PATCH : 요청을 보낸 데이터만 업데이트하기, 서버에 없는 컬럼을 요청시 서버에서 따로 예외 처리를 만들어야한다.
DELETE : 데이터 삭제하기
위의 네가지가 있다.
HEAD : GET과 동일하지만 메시지 부분(body 부분)을 제외하고, 상태 줄과 헤더만 반환
OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행
매서드 요청을 할때는 RESTful api라는 표준을 따르는 것이 일반적이다.
웹을 망가뜨리지 않고 HTTP기능을 발전시키기 위한 방식이다.
예를 들어서 웹/브라우저는 둘 중 하나가 업데이트 되었다고 해서 다른 한쪽을 업데이트할 필요가 없으며, HTTP/HTML 명세서가 바뀌어도 잘 작동한다. 앱의 경우 서버를 변경한 뒤 클라이언트가 따라 올 수 없으면 강제로 업데이트를 하는것과 반대이다.
이것을 상호운용성(interoperability)이라고 한다. 이것을 지키기 위해서 잘못짓거나 오타를 낸 것들도 그대로 가져간다. 그렇게 해야지 상호운용성을 지킬 수 있기 때문이다.
이하는 RESTful API의 특성이다.
Client-Server : 서버와 클라이언트의 역할이 나뉜다는 것이다.
- 서버 : API 제공
- 클라이언트 : 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리
Stateless : 서버가 클라이언트의 상태를 기억하지 않고, 들어오는 요청만 처리한다는 것이다.
Cache : HTTP 표준을 따르기 때문에, HTTP의 캐싱 기능을 사용할 수 있다.
Uniform Interface : REST와는 또 다른 아키텍쳐 스타일이다.
- Identification of resources : url로 리소스가 식별되어야한다.
- Manipulation of resources through representations :
representations 즉, http 메시지에 삭제/수정등의 표현이 있어야한다는 뜻이다. - Self-descriptive messages : 요청값과 응답값의 메시지만 보고 모든 것을 이해할 수 있어야한다.
- HATEOAS (Hypermedia as the engine of application state) :
하이퍼링크를 따라감으로써 애플리케이션의 상태를 바꿀 수 있어야한다.
Layered System : 보안, 로드 밸런싱, 암호화 계층 등을 추가해 구조상의 유연성을 둘 수 있다.
또한, PROXY, 게이트웨이와 같은 네트워크 기반의 중간매체를 사용할 수 있다.
슬래시 구분자/로 계층관계를 나타낸다. 그렇기 때문에 url의 마지막에는 /를 사용하지 않는다.
Code-on-Demand (optional) : 서버에서 코드를 클라이언트로 보내서 실행시킬 수 있어야한다.(자바스크립트를 의미)
또한 가독성을 이유로 소문자와 -만 사용한다고 한다.
일주일간 공부하며 느낀 점
협업은 너무 심오한것같다.
땨로하면 스타일이 따로 놀아서 힘들고, 하나로 합치면 한명한명이 자신의 스타일에대한 완벽한 이해가 없으니 또 굴러가지 않는 뼈대가 만들어졌다. 협력도 중요하지만 개인의 역량도 중요하다고 느낀 한 주 였다.
참조한 페이지
탈퇴 영어로 (withdraw, resign, quit, leave, cancel 차이, 뜻)
HTTP 메서드 종류 & 요청 흐름 💯 총정리
CS & Develop ETCAPI Versioning 전략
REST 서버, REST API란?
