코드저장소

협상(콘텐츠 네고시에이션) 헤더 협상이란 클라이언트가 선호하는 표현 요청을 이야기 한다. 좀 더 쉽게 설명하자면 클라이언트가 선호하는 표현을 요청하면 서버에서 여러가지 표현 방법 중 클라이언트가 선호하는 표현으로 응답을 만들어 보내는 것을 말한다. 협상에는 미디어 타입, 인코딩, 자연언어 등이 표현되며 각각을 표현하는 요청 헤더는 다음과 같다. Accept : 클라이언트가 선호하는 미디어 타입 Accept-Charset : 클라이언트가 선호하는 문자 인코딩 Accept-Encoding : 클라이언트가 선호하는 압축 인코딩 Accept-Language : 클라이언트가 선호하는 자연 언어 이러한 협상 헤더는 클라이언트가 보내는 것이기에 요청시에만 사용되는 것이 특징이다. 또한, 협상의 경우 클라이언트가 선호..

HTTP 헤더 개요 HTTP 헤더의 구성은 다음과 같다. header-field = field-name ":" OWS field-value OWS (OWS : 띄어쓰기 허용) ex) Host: www.google.com *field-name은 대소문자 구분이 없다. HTTP 헤더에는 HTTP 전송에 필요한 모든 부가 정보가 들어가게 되며 메시지 바디의 내용, 크기, 압축,인증, 요청 클라이언트, 서버 정보 등 무수한 정보를 넣을 수 있다. 과거 RFC2616에서는 헤더를 크게 4가지로 분류하였는데 다음과 같이 나뉜다. General 헤더 : 메시지 전체에 적용되는 정보 (ex. Connenction) Request 헤더 : 요청 정보 (ex. user-Agent) Response 헤더 : 응답 정보 (e..

1. 3xx (Rediretion) 300번대의 상태코드는 요청을 완료하기 위하여 유저 에이전트의 추가 조치가 필요한 것을 의미한다. 유저 에이전트는 클라이언트 프로그램을 말하며 대부분의 경우 브라우저이다. 300번대의 대표적인 상태 코드는 다음과 같다. 300 Multiple Choices 301 Moved Permanently 302 Found 303 See Other 304 Not Modified 307 Temporary Redirect 308 Permanent Redirect 이 중에서 300은 거의 사용되지 않으며 301 ~ 308은 중요하게 사용된다. 300번대를 설명하기 전에 리다이렉션에 대해서 이해를 할 필요성이 있다. 웹 브라우저는 300번대의 응답의 결과에 Location 헤더가 있으면..

HTTP 상태 코드란? HTTP 상태 코드는 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려 주는 기능이다. 인터넷을 사용하다보면 403 Error라는 것을 가끔 보았을 것이다. 여기서 403이 바로 HTTP 상태 코드이다. 상태 코드는 크게 5분류로 이루어 진다. 1xx (Informational): 요청이 수신되어 처리중 2xx(Successful): 요청 정상 처리 3xx(Rediretion): 요청을 완료하려면 추가 행동이 필요 4xx(Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음 5xx(Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함 만약, 클라이언트가 인식 할 수 없는 상태코드를 서버가 반환한다면 클라이언트는 상위의 ..

POST 기반 API와 PUT 기반의 API 1. Post 기반의 등록 회원 등록이라는 기능을 HTTP API를 통하여 만든다고 생각해보자. 우리는 POST 메서드를 이용하여 /members라는 URI를 통하여 회원 정보를 등록하게 될 것이다. URI를 잘 보면 뒤에 쿼리 파라미터가 따로 필요가 없는 것을 확인 할 수 있다. 이것은 POST는 바디를 통해 전달 받은 데이터를 어떻게 처리할 지 서로 규약을 통해 알고 있기 때문이다. 이때, /members를 Collection이라고 한다. Collection은 서버가 관리하는 리소스 디렉토리를 말하며 서버가 리소스의 URI를 생성하고 관리하는 것을 말한다. 또한, 앞선 강의에서 설명했듯 POST는 서버가 리소스 URI를 결정하기 때문에 클라이언트가 등록될 ..

이번 시간에는 HTTP 메서드를 활용하여 HTTP API를 설계하는 방법을 배워 보겠다. 클라이언트에서 서버로 데이터 전송하기 클라이언트에서 서버로 데이터를 전달하는 방식은 크게 2가지가 있다. 쿼리 파라미터를 통한 데이터 전송 GET에서 사용 주로 정렬 필터(검색어) 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH에서 사용 회원 가입, 상품 주문, 리소스 등록, 리소스 변경.... 그럼 4가지 상황을 가정해 보고 각각의 상황에서 데이터가 어떻게 전송되는지 생각해보자. 1. 정적 데이터를 조회하는 경우 만약 클라이언트가 이미지나 텍스트문서 같은 정적인 데이터를 받는 경우 쿼리 파라미터를 사용하지 않는다. GET 메서드를 통해서 주어진 URL로 들어가게만 하면 되기 때문이다. 즉, 추가적인 ..

HTTP 메서드의 속성 HTTP 메서드는 3가지 큰 특징을 가진다. 안전(Safe Methods) 멱등(Idempotent Methods) 캐시가능(Casheable Methods) 이번 시간에는 이런 HTTP 메서드의 속성에 대하여 알아보자. 안전 안전이라는 특징은 호출해도 리소스를 변경하지 않는것을 의미한다. 그런 점에서 GET,HEAD와 같은 메서드는 리소스를 변경하지 않으므로 안전하다고 할 수 있다. 단, 안전은 해당 리소스의 변경만 고려하므로 로그가 쌓여서 발생하는 장애같은 것은 고려하지 않는다. 어디까지나 리소스에 대해서만 생각해야 한다. 멱등 멱등이라는 것은 몇번을 호출하든 같은 결과를 반환하는 것을 말한다. 조금 헷갈릴 수 있는데 여기서 같은 결과를 반환한다는 것은 요청이 같을 때 메서드로..

PUT put은 리소스를 대체하는 메서드이다. 다만 리소스가 없으면 생성하고, 리소스가 있으면 대체한다. 예를 들어, 우리가 파일을 저장할때 같은 이름이 없으면 생성하고, 없으면 덮어씌우는 것과 같은 동작이다. PUT을 사용할 때 중요한 점이 있는데 클라이언트가 리소스를 식별한다는 것이다. 이게 무슨 말이냐면 이전에 POST 메시지를 살펴보자. POST /members HTTP/1.1 Content-Type: application/json { "userId":"1", "username":"hong" } URI를 보면 뒤에 /{id}값이 없다. 이는 POST 메서드는 클라이언트가 리소스를 식별하는 것이 아니라 POST로 들어온 데이터를 서버가 처리하는 것이 주 목적이기 때문이다. 하지만 PUT의 경우는 클..

HTTP API 설계 이번에는 HTTP API를 설계하는 과정을 배워보자. 당신에게 회원기능에 대한 API를 설계하라는 요청이 들어왔다. 회원 기능은 회원가입, 회원조회, 회원정보 수정, 회원 탈퇴의 4가지 기능이 있다고 가정한다. 그럼 가장 먼저 URI를 설계하게 될 것이다. 우리는 일반적인 명명규칙에 따라 회원가입 : /join-member/ 회원조회 : /read-member/ 회원정보 수정 : /update-member/ 회원탈퇴 : /delete-member/ 라고 URI를 작성하였다. 얼핏 보면 굉장히 잘 설계된 URI처럼 보이지만 실은 그렇지 않다. URI에서 가장 중요한 것은 리소스를 식별하는 것이기 때문이다. 그렇다면 우리 요구사항에서 리소스는 뭘까? 바로 회원이라는 개념 자체가 리소스가..

HTTP란? http는 Hyper Text Transfer Protocol의 약자이다. 처음 시작은 하이퍼 텍스트를 전송하는 프로토콜로 시작하였으나 현대에는 거의 모든 형태의 데이터 전송이 가능하다. 또한 서버간의 데이터를 주고 받을 때도 대부분 HTTP를 사용한다. 현재 가장 많이 사용되는 버전은 HTTP/1.1로 대부분의 기능이 다 들어있으며 그 위의 버전은 대부분 성능 개선에 초점이 맞추어져 있다. 또한, HTTP/1.1, HTTP/2는 TCP 기반으로 동작하며 HTTP/3는 UDP에서 동작한다. HTTP의 특징 HTTP는 클라이언트 서버 구조로 동작하며 무상태 프로토콜(스테이스리스), 비연결성이란 특징을 지닌다. 또한, HTTP 메시지를 통해 통신을 하며 단순하고 확장이 가능하다는 특징이 있다. ..