HTTP 헤더1. 일반헤더 HTTP 헤더의 구조'필드이름: 필드값 '- 필드값 앞 뒤로 띄어쓰기 가능- 필드이름은 대소문자 구분이 없다ex : Host: http://www.google.com HTTP 헤더의 용도- HTTP 전송에 필요한 모든 부가정보를 전달 (메시지 바디의 내용, 바디의 크기, 압축, 인증, 요청 클라이언트, 서버정보 등)- 표준 헤더가 많음- 필요하면 임의의 헤더 추가도 가능 HTTP 헤더의 과거 (1999년 RFC2616) General 헤더 : 메시지 전체에 적용되는 정보 Request 헤더 : 요청 정보 Response 헤더 : 응답 정보 Entity 헤더 : 엔티티 바디 정보 (폐기됐음) - 과거엔 메시지 본문(message body)는 엔티티 본문을 전달하는데 사용..
HTTP 상태코드클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능너무 많아서 사용하는건 그냥 케바케 Informational ( 1XX )요청이 수신되어 처리중 (안씀) Successful ( 2XX )요청 정상 처리 200 (OK) 성공(그냥 200만 쓰는 경우도 많음)201 (Created) 요청 성공해서 새로운 리서스 생성.. POST 요청 → 생성ㅇㅋ202 (Accepted)요청이 접수는 됏는데 처리는 X .. 배치 처리가 필요한 경우! (잘 안씀)204 (No Content)요청은 성공했지만, 응답 페이로드 본문에 보낼 데이터가 없음.(save기능 같은거 .. 저장해도 그냥 성공 여부만 필요한 경우) Redirection ( 3XX )요청을 완료하려면 추가 행동이 필요3X..
HTTP API 설계(1) 컬렉션(Collection) 방식 - 대부분이 이 방식을 사용- POST 기반 등록 예를 들어서 '회원 관리 시스템 API' 라고 했을 때여기서 리소스는 '회원'회원 목록/membersGET회원 등록/membersPOST회원 조회/members/{id}GET회원 수정/members/{id}PATCH(부분수정-회원정보),PUT(덮어쓰기-게시글),POST회원 삭제/members/{id}DELETE- 클라이언트는 새로 등록될 리소스의 URI를 모른다!회원 등록을 하면 클라이언트는 id 모름. 아니, 몰라도 된다.그래서 서버가 새로 등록된 리소스 URI를 생성해준다.HTTP/1.1 201 CreatedLocation: /members/100- 서버가 관리하는 리소스 디렉토리 - 서버가..
HTTP 메서드API 만드는 과정(1) 요구사항 확인(2) API URI 설계(3) 리소스와 행위를 분리 가장 중요한 건 리소스를 식별하는 것이다.요구사항이 '회원 정보 관리 API를 만들기' 라면, '회원 등록하기'에서의 리소스는 '등록'이 아닌 '회원'이라는 것!행위 → 조회, 등록, 삭제, 변경 (GET, POST, PUT, PATCH, DELETE) HTTP 메서드 종류GET : 리소스 조회POST : 요청 데이터 처리, 주로 등록에 사용PUT : 리소스를 대체, 해당 리소스가 없으면 생성PATCH : 리소스 부분 변경DELETE : 리소스 삭제아래는 안쓰는 메서드HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환OPTIONS : 대상 리소스에 대한 통신 가능 옵션..
HyperText Transfer Protocol- HTML, TEXT 뿐만 아니라 이미지, 음성, 영상, 파일, JSON, XML(API) 모두 전송 가능- 심지어 서버간에 데이터를 주고 받을 때도 사용 HTTP 역사- HTTP/0.9 1991년 : GET 메서드만 지원, HTTP 헤더 없음- HTTP/1.0 1996년 : 메서드, 헤더 추가됨- HTTP/1.1 1997년 : 모든 기능, 가장 많이 사용RFC2016(1197) → RFC2616(1999) → RFC7230~7235(2014)- HTTP/2 2015년 : 성능 개선- HTTP/3 진행 중 : TCP 대신 UDP 사용, 성능 개선 HTTP 기반 프로토콜- TCP : HTTP/1.1, HTTP/2- UDP : HTTP/3- 현재 1.1을..