728x90
반응형
HTTP의 특징
클라이언트 - 서버 구조
- 요청/응답 모델(Request/Response Model) 구조
- 클라이언트에서 요청을 보내고, 서버에서는 응답을 반환함
- 모델은 클라이언트와 서버간의 상호작용을 단순화함
- 데이터 전송의 신뢰성과 안정성을 보장하는 데에 큰 역할을 한다
비상태성 (Stateless)
- 연결 상태를 유지하지 않는 비상태성 프로토콜이다
- 서버의 부담을 줄이고, 웹 서버의 확장성을 향상시기는 데에 기여
- 세션 로그인은 상태가 있다. 최소한으로만 사용한다는 개념
비연결성 (Connectionless)
- 클라이언트와 서버 간의 연결이 유지되지 않음
- 클라이언트가 서버에 요청을 보내고 서버가 응답하면 연결은 끊어짐
- 서버의 부하를 줄이고, 성능을 향상시키는데에 기여함
- but, 이전 상태 정보가 유지되지 않는 다는 단점도 있음 이것을 보완하기위해 쿠키와 같은 메커니즘이 사용됨
HTTP 메시지
- 요청 메시지와 응답 메시지가 조금 다르게 생겼다
- 포스트맨에서 직접 확인해보자
콘솔에서 raw log를 보면 더 직관적으로 보인다
각 메시지의 상단 라인을 보면
요청 (Request) 메시지는
요청 메소드 / 연결 / 버전 이고
응답 (Response) 메시지는
연결 / 버전 / 응답 이다
HTTP Method
- 안 좋은 설계의 예 회원 목록 : /userlist 회원 조회 : /user/<int:pk> 회원 생성 : /user/create 회원 수정 : /user/update 회원 삭제 : /user/delete
- 리소스 식별을 위해 메소드를 정한다 [GET] 회원 목록 : /user [GET] 회원 조회 : /user/<int:pk> [POST] 회원 생성 : /user/<int:pk> [PUT] 회원 수정 : /user/<int:pk> [DELETE] 회원 삭제 : /user/<int:pk>
- 리소스와 행위를 분리하는 것이 Restful API
- 리소스 : 회원
- 행위 : 조회, 등록, 삭제, 변경
특징
- 클라이언트는 등록될 리소스의 URI를 모른다
- 서버가 리소스의 URI를 생성한다
- /user 가 컬렉션이 된다
Method
- GET : 조회
- 데이터는 쿼리스트링으로 전달
- POST : 등록
- 메시지 바디를 통해 서버로 요청, 데이터 전달
- 데이터를 처리
- 프로세스를 처리해야 하는 경우
- 반드시 새로운 리소스가 생기는 것은 아니다
- JSON으로 조회 데이터를 넘기고 싶은데 GET 메서드를 쓰기 힘든 경우에 쓴다
- GET은 캐싱을 할 수 있어서 가능한경우 GET을 사용
- PUT : 대체, 혹은 생성
- 없으면 만들고 있으면 덮어쓴다
- POST와 차이점은 PUT은 클라이언트가 URI를 지정해서 보낸다
- PATCH : 부분 변경
- HEAD : GET과 동일하지만 상태줄과 헤더만 반환
Method의 속성
- 안전 (Safe)
- 서버의 상태를 변경하지 않는 메소드를 의미
- GET, HEAD
- 멱등 (Idempotent)
- 여러번 실행해도 결과가 같은 메소드를 의미
- 같은 리소스에 대한 중복 요청이 발생하더라도, 리소스의 상태가 동일하게 유지되는 메소드
- PUT, DELETE
- 캐시 가능 (Cacheable)
- 응답 결과를 캐시 할 수 있는 메소드를 의미
- GET, HEAD
데이터 전송 방식
쿼리 파라미터
- GET
- 주로 검색, 정렬 필터
메시지 바디
- POST, PUT, PATCH
- 회원가입, 상품주문, 리소스 등록 변경
HTML Form을 통한 데이터 전송
- 회원가입, 주문, 데이터 변경
- HTML Form은 GET, POST만 지원한다
HTTP API를 통한 데이터 전송
- 회원가입, 주문, 데이터 변경
- 웹 페이지에서 페이지 이동 없이 데이터를 서버로 전송 가능
- Form 대신 JS를 이용, AJAX (Asynchronous JavaScript and XML)
Uploaded by N2T
728x90
반응형