BackEnd지만 네트워크 모를수 없지만 뒤돌아서면 까먹는다.
이 글에 필요한 지식들을 알짜배기로 적어 넣어놨다.
잊어버릴때마다 보고 또 보고 복습하자.
RESTful API한 설계
REST API가 무엇인지는 알고있다. 하지만 이것이 정말 RESTful한가? 라고 물어보면 글쎄…
무작정 POST로만 HTTP 메소드를 생성하고 있었고 네이밍 규칙은 지키지 않았다. 정답이 있는 질문은 아니지만 Best Pratice는 있다고 생각한다.
REST API 설계 가이드
- URL에선 동사대신 명사를 사용한다.
- 리소스에 대한 행위는 GET, POST, PUT, DELETE만 사용한다.
- /는 계층관계를 나타내며 마지막에 사용하지 않는다.
- URI에 언더스코어를 사용하지 않으며 소문자를 사용한다.
- URI에 파일 확장자를 포함하지 않는다.
HTTP Method
| 메소드 | 안전성 | 멱등성 |
|---|---|---|
| GET | O | O |
| POST | X | X |
| PUT | X | O |
| DELETE | X | O |
안전성이란 보안이랑 관계없이 호출해도 리소스가 변경되지 않는 성질을 의미한다. GET은 리소스를 조회할 때 사용된다. {key}로 데이터를 조회할때 외부에서의 방해가 없다면 항상 같은 값을 반환해야 한다.
멱등성은 동일한 요청을 한번 보내는 것과 여러번 연속으로 보내는 것이 같은 효과를 갖고, 서버의 상태도 동일하게 남는것을 의미한다. 응답 상태 코드가 아닌 서버의 상태가 동일하다는 점을 유의하자.
DELETE로 자료를 삭제하고 또 삭제하려고 하면 정상적으로 삭제가 되지 않을텐데 왜 멱등하냐고? 서버의 상태는 리소스가 삭제된 상태를 반환하니까
HTTP VS HTTPS
HTTPS = HTTP + SSL
HTTP의 보안 문제를 강화하기 위해 나온것이 HTTP라 할수있다.
HTTP의 보안적인 문제는 무엇이 있었고 어떻게 해결 한걸까?
- 평문 통신이어서 도청 가능
- 통신 암호화 & 컨텐츠 암호화 → TLS 프로토콜을 사용한다.
- 통신 상대를 확인하지 않으므로 위조 가능
- SSL은 상대방을 확인할 수 있는 증명서를 제공
- 완전성을 증명할 수 없어서 변조 가능
- MD5 & SHA-1등의 해시값을 사용
HTTPS는 HTTP보다 암호화 과정등을 거치기 때문에 속도가 느려서 적절히 사용하라곤 했지만 이는 옛말이다. 지금은 무의미할 정도로 차이가 난다. 추가적으로 검색엔진에도 노출이 더 잘된다!
이런 이유들로 HTTPS를 사용하지 않을 이유가 더더욱 없다.
쿠키와 세션의 차이
HTTP의 두가지 특징을 알아야 한다.
- Connectionless: 클라이언트가 요청한 후 응답을 받으면 연결을 끊어버린다.
- Stateless: 통신이 끝나면 상태를 유지하지 않는다.
이전 통신을 저장하지 않기 때문에 매번 인증을 해줘야 한다. 나는 로그인을 하였으니 “장바구니” 목록을 보려면 또 로그인을 해줘야 하는 불편함이 생긴다. 이를 해결하기 위한게 쿠키와 세션이다.
쿠키는 클라이언트가 페이지를 요청하면 웹 서버가 쿠키를 생성하고 HTTP화면과 함께 쿠키를 돌려준다. 그렇게 사용자 로컬 PC에 쿠키를 갖고 있다가, 재방문시 쿠키가 있다면 쿠키도 같이 전송한다.
ex) “아이디와 비밀번호를 저장하시겠습니까?”, “일주일간 이 창을 다시 보지 않습니다.”
세션은 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고 유지시킨다. 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위를 세션이라 생각하자. ex) 화면을 이동해도 로그인이 풀리지 않는다.
두 가지의 차이점은 상태 정보의 저장 위치다. 쿠키는 클라이언트에 저장하고, 세션은 서버에 저장한다.
쿠키는 로컬PC에 저장되므로 서버의 자원을 사용하지 않는다. 다만 보안 면에서는 세션이 session-id만 저장하고 처리하기 때문에 더욱 유리하다.
HTTP 1.1과 비교하여 더 나은 2.0
- Multiplexing
- HTTP/1.1: 요청과 응답을 순차적으로 처리하기 때문에 여러 요청이 온다면 병목 현상이 발생한다.
- HTTP/2.0: 하나의 TCP 연결을 통해 여러개의 요청과 응답을 처리한다.
- Header Compression
- HTTP/1.1: 요청과 응답을 텍스트로 전송하여 불필요하게 큰 헤더를 갖고있다.
- HTTP/2.0: HPACK압축 알고리즘을 사용하여 헤더를 압축한다. 대역폭을 절약하고 더 빠른 전송이 가능하다.
- Server Push
- HTTP/1.1: 클라이언트가 요청하지 않은 자원을 서버가 미리 보내는 기능을 제공하지 않음
- HTTP/2.0: 서버가 클라이언트의 요청 없이도 필요한 리소스를 미리 전송한다.
- Prioritization
- HTTP/1.1: 요청에 대한 우선순위를 관리하지 못한다.
- HTTP/2.0: 스트림 우선순위를 지원하여 중요한 리소스 먼저 처리 우선권을 부여한다.
위 장점들로 인해 2.0은 1.0보다 Lower Latency를 제공한다.
