클라이언트 서버 구조
클라이언트가 서버에 요청을 보내고 서버가 결과를 응답
무상태 프로토콜(Stateless)
- 서버가 클라이언트 상태를 보존하지 않는 것,
- 서버가 바뀌어도 요청을 처리할 수 있다
단, 요청하는 데이터 양이 많다는 단점이 있다.
exc) 로그인 같은 서비스는 상태유지로 처리
비연결성
요청을 받고 응답을 보내는 동시에 연결을 끊음
--> 서버 자원 최소한 유지
- 한계점 해결 : 지속 연결을 통해 속도 개선
시작라인 : 요청-메서드 / 응답-상태코드
헤더 : 전송에 필요한 모든 부가 정보
공백라인
body: 실제 전송 데아터 (html, image, 영상, json 등..)
URI 설계는 리소스 식별을 기준으로 설계하자!
* 리소스와 행위를 분리하자 !
리소스 : 멤버
행위 : 등록 / 수정 / 삭제 / 조회
- GET : 쿼리를 통해 서버로 요청 데이터 전달 / 리소스 조회
- POST : 메시지 바디를 통해 서버로 요청 데이터 전달 / 요청 데이터 처리
** 애매하면 POST 사용 !- PUT : 리소스가 있으면 대체, 없으면 생성
클라이언트가 리소스를 식별 (post와 차이점)- PATCH : 리소스 부분 변경 (PUT과 차이점)
- DELETE : 리소스 제거
- 안전 : 호출해도 리소스를 변경하지 않는다.
ex) GET, HEAD- 멱등 : 동일한 호출을 100번 해도 결과는 똑같다.
ex) GET, PUT, DELETE
** POST는 멱등이 아님! (두 번 결제하면 중복 결제!)- 캐시가능 : 응답 결과 리소스를 캐시해둠
ex) GET, HEAD 정도만 사용,,
클라이언트에서 서버로 데이터전달
HTTP API 설계 (주로 JSON)
HTML FORM 사용
✅ 정리 !
- 문서(document)
단일 개념 (파일 하나, 객체 인스턴스, 데이터베이스 row)
예) /members/100, /files/star.jpg- 컬렉션(collection)
서버가 관리하는 리소스 디렉터리
서버가 리소스의 URI를 생성하고 관리
예) /members- 스토어(store)
클라이언트가 관리하는 자원 저장소
클라이언트가 리소스의 URI를 알고 관리
예) /files- 컨트롤러(controller), 컨트롤 URI
문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
동사를 직접 사용
예) /members/{id}/delete