HTTP 프로토콜과 REST 소개

출처

http://rhammer.tistory.com/115

https://ko.wikipedia.org/wiki/HTTP

http://hyunalee.tistory.com/1

http://bcho.tistory.com/953

HTTP 란

HyperText Transfer Protocol 의 약자로, www 상에서 정보를 주고받을 수 있는 프로토콜이다.

주로 HTML 문서를 주고받는데 쓰인다.

TCP 와 UDP 를 사용하며, 80포트를 사용한다.

HTTP 는 request/response 프로토콜이다.

예를들면 클라이언트인 웹 브라우저가 HTTP 를 통하여

서버로부터 웹페이지나 그림정보를 요청하면

서버는 이 요청에 응답하여 필요한 정보를 브라우저에 전달한다.

HTTP 응답 코드 정리

클라이언트가 서버에 접속하여 어떠한 요청을 하면

서버는 세자리 수로 된 응답 코드를 돌려준다.

코드	메시지	설명
1XX	Informational(정보)	정보 교환.
100	Continue	클라이언트로부터 일부 요청을 받았으니 나머지 요청 정보를 계속 보내주길 바람. (HTTP 1.1에서 처음 등장)
101	Switching Protocols	서버는 클라이언트의 요청대로 Upgrade 헤더를 따라 다른 프로토콜로 바꿀 것임. (HTTP 1.1에서 처음 등장)
2XX	Success(성공)	데이터 전송이 성공적으로 이루어졌거나, 이해되었거나, 수락되었음.
200	OK	오류 없이 전송 성공.
202	Accepted	서버가 클라이언트의 요청을 수락함.
203	Non-authoritavive Information	서버가 클라이언트 요구중 일부만 전송.
204	Non Content	클라이언트의 요구를 처리했으나 전송할 데이터가 없음.
205	Reset Content	새 문서 없음. 하지만 브라우저는 문서 창을 리셋해야 함. (브라우저가 CGI 폼 필드를 전부 지우도록 할 때 사용됨.) (HTTP 1.1에서 처음 등장)
206	Partial Content	클라이언트가 Range 헤더와 함께 요청의 일부분을 보냈고 서버는 이를 수행했음. (HTTP 1.1에서 처음 등장)
3XX	Redirection(방향 바꿈)	자료의 위치가 바뀌었음.
300	Multiple Choices	최근에 옮겨진 데이터를 요청.
301	Moved Permanently	요구한 데이터를 변경된 URL에서 찾았음.
302	Moved Permanently	요구한 데이터가 변경된 URL에 있음을 명시. 301과 비슷하지만 새 URL은 임시 저장 장소로 해석됨. [8]
303	See Other	요구한 데이터를 변경하지 않았기 때문에 문제가 있음.
304	Not modified	클라이언트의 캐시에 이 문서가 저장되었고 선택적인 요청에 의해 수행됨 (보통 지정된 날짜보다 더 나중의 문서만을 보여주도록 하는 If-Modified-Since 헤더의 경우). [9]
305	Use Proxy	요청된 문서는 Location 헤더에 나열된 프록시를 통해 추출되어야 함. (HTTP 1.1에서 처음 등장)
307	Temporary Redirect	자료가 임시적으로 옮겨짐.
4XX	Client Error(클라이언트 오류)	클라이언트 측의 오류. 주소를 잘못 입력하였거나 요청이 잘못 되었음.
400	Bad Request	요청 실패. 문법상 오류가 있어서 서버가 요청사항을 이해하지 못함, [10]
401.1	Unauthorized	권한 없음 (접속실패). 서버에 로그온 하려는 요청사항이 서버에 들어있는 권한과 비교했을 때 맞지 않음. [11]
401.2	Unauthorized	권한 없음 (서버설정으로 인한 접속 실패). 서버에 로그온 하려는 요청사항이 서버에 들어있는 권한과 비교했을 때 맞지않음. [12]
401.3	Unauthorized	권한 없음 (자원에 대한 ACL에 기인한 권한 없음). 클라이언트가 특정 자료에 접근할 수 없음. [13]
401.4	Unauthorized	권한 없음 (필터에 의한 권한 부여 실패). 서버에 접속하는 사용자들을 확인하기 위해 설치한 필터 프로그램이 있음. [14]
401.5	Unauthorized	권한 없음 (ISA PI/CGI 애플리케이션에 의한 권한부여 실패). 이용하려는 서버의 주소에 ISA PI나 CGI프로그램이 설치되어 있고, 권한을 부여할 수 없음. [15]
402	Payment Required	예약됨.
403.1	Forbidden	금지 (수행접근 금지). 수행시키지 못하도록 되어있는 디렉터리 내의 실행 파일을 수행하려고 하였음.
403.2	Forbidden	금지 (읽기 접근 금지). 접근한 디렉터리에 가용한 기본 페이지가 없음. [16]
403.4	Forbidden	금지 (SSL 필요함). 접근하려는 페이지가 SSL로 보안유지 되고 있음. [17]
403.5	Forbidden	금지 (SSL 128필요함). 페이지가 128비트의 SSL로 보안유지 되고 있음. [18]
403.6	Forbidden	금지 (IP 주소 거부됨). 사용자가 허용되지 않은 IP로부터 접근함.
403.7	Forbidden	금지 (클라이언트 확인 필요). 클라이언트가 자료에 접근할 수 있는지 확인 요함. [19]
403.8	Forbidden	금지 (사이트 접근 거부됨). 서버가 요청사항을 수행하고 있지 않거나, 해당 사이트에 접근하는 것이 허락되지 않음.
403.9	Forbidden	접근금지 (연결된 사용자수 과다). 서버가 BUSY 상태에 있어서 요청을 수행할 수 없음.
403.10	Forbidden	접근금지 (설정이 확실 하지 않음).
403.11	Forbidden	접근금지 (패스워드 변경됨). 잘못된 암호를 입력했음.
403.12	Forbidden	접근금지(Mapper 접근 금지됨). 클라이언트 인증용 맵이 해당 웹 사이트에 접근하는 것이 거부됨.
404	Not Found	문서를 찾을 수 없음. 서버가 요청한 파일이나 스크립트를 찾지 못함.
405	Method not allowed	메서드 허용 안됨. 요청 내용에 명시된 메서드를 수행하기 위해 해당 자원의 이용이 허용되지 않음. [20]
406	Not Acceptable	받아들일 수 없음. [21]
407	Proxy Authentication Required	프록시 서버의 인증이 필요함. [22]
408	Request timeout	요청 시간이 지남.
409	Conflict	요청을 처리하는 데 문제가 있음. 보통 PUT 요청과 관계가 있다. 보통 다른 버전의 파일을 업로드할 경우 발생함. (HTTP 1.1에서 새로 등장)
410	Gone	영구적으로 사용할 수 없음.
411	Length Required	클라이언트가 헤더에 Content-Length를 포함하지 않으면 서버가 처리할 수 없음.(HTTP 1.1에서 새로 등장)
412	Precondition Failed	선결조건 실패. 헤더에 하나 이상의 선결조건을 서버에서 충족시킬 수 없음. [23]
413	Request entity too large	요청된 문서가 현재 서버가 다룰 수 있는 크기보다 큼. [24] (HTTP 1.1에서 새로 등장)
414	Request-URI too long	요청한 URI가 너무 김. [25]
415	Unsupported media type	요청이 알려지지 않은 형태임. (HTTP 1.1에서 새로 등장)
5XX	Server Error(서버 오류)	서버 측의 오류로 올바른 요청을 처리할 수 없음.
500	Internal Server Error	서버 내부 오류. [26]
501	Not Implemented	필요한 기능이 서버에 설치되지 않았음. [27]
502	Bad gateway	게이트웨이 상태 나쁨. [28]
503	Service Unavailable	외부 서비스가 죽었거나 현재 멈춘 상태 또는 이용할 수 없는 서비스. [29]
504	Gateway timeout	프록시나 게이트웨이의 역할을 하는 서버에서 볼 수 있음. 초기 서버가 원격 서버로부터 응답을 받을 수 없음. (HTTP 1.1에서 새로 등장)
505	HTTP Version Not Supported	해당 HTTP 버전을 지원하지 않음.

REST 란

REpresentational Safe Transfer 의 약자이다.

개발자들이 웹을 사용할 때 본래 설계의 우수성을 잘 사용하지 못하고 있다고 판단했고,

이에 HTTP 창시자 중 한사람인 Roy Fielding 의 논문에서 소개되었다.

REST 는 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍쳐다.

(내 생각엔, 네트워크 기반 아키텍쳐라고 하니 어려워보이는데

웹 사용 시 rule 이라고 생각해도 되지 않을까 싶다...)

기본 형식

REST 는 리소스, 메서드, 메시지 총 3가지 요소로 구성된다.

HTTP POST , http://myweb/users/ {      "users":{         "name":"terry"    } }

위 예제에서의 리소스, 메서드, 메시지는 아래와 같다.

리소스 : "users"

메서드 : "POST"

메시지 : "name : terry"

HTTP 메서드

REST 에서는 CRUD 에 해당하는 GET, POST, PUT, DELETE 만 사용한다.

메서드	의미	Idempotent
POST	Create	NO
GET	Select	YES
PUT	Update	YES
DELETE	Delete	YES

Idempotent 라는 뜻은 여러 번 수행해도 결과가 같은 경우를 말한다.

REST 의 리소스

리소스 지향 아키텍쳐 스타일이라는 정의 답게 모든 것을 리소스 (명사) 로 표현하며

각 세부 리소스에는 id 를 붙인다.

즉, 사용자라는 리소스 타입을 http://myweb//users 라고 정의했다면

terry 라는 id 를 갖는 리소스는 http://myweb/users/terry 라는 형태가 되어야한다.

REST 의 리소스가 명사의 형태를 띄우나 보니, 

명령성의 API 를 정의하는 것에서 혼돈이 올 수 있다. (/myweb/sendpush) 

위 예제를 변경해보면, API 포멧은 (POST/myweb/push) 와 같이 변경되어야한다.

모든 명령이 위와 같은 형태로 정의가 가능하지는 않겠지만

되도록이면 리소스 기반의 명사 형태로 정의를 하는게 REST 형태의 디자인이 된다.

POST	GET	PUT	DELETE
HTTP POST, http://myweb/users/ {      "name":"terry",    "address":"seoul" }	HTTP GET, http://myweb/users/terry	HTTP PUT, http://myweb/users/terry {      "name":"terry",    "address":"suwon" }	HTTP DELETE, http://myweb/users/terry

특성

유니폼 인터페이스 / Uniform Interface

REST 는 HTTP 표준에만 따른다면 어떤 기술이라던지 사용지 가능한 인터페이스 스타일이다.

예를 들어 HTTP + JSON 으로 REST API 를 정의했다면

Android, iOS, C, Java, Python 등 특정 언어나 OS, 기술에 종속받지 않고

모든 플랫폼에 사용이 가능하다.

무상태성 / Stateless

상태가 있다 없다는 의미는 사용자나 클라이언트의 context 를 

서버쪽에 유지하지 않는다는 의미로

HTTP Session 과 같은 Context 저장소에 상태 정보를 저장하지 않는 형태를 의미한다.

캐싱가능 / Cacheable

REST 는 HTTP 라는 기존의 웹 표준을 그대로 사용하기 때문에

웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다.

HTTP 프로토콜 기반의 로드 밸런서나 SSL, Caching 등을 그대로 적용할 수 있다.

캐쉬를 사용하면 응답 시간 뿐 아니라 REST 컴포넌트가 위치한 서버에

트랜잭션을 발생시키기 않기 때문에 전체 성능, 자원 사용률을 향상시킬 수 있다.

자체 표현 구조 / Self-descriptiveness

API 메시지 자체만 보고도 API 를 이해할 수 있는 자체 표현 구조를 갖는다는 것이다.

리소스와 메서드를 이용해서 어떤 메서드에 무슨 행위를 하는지 알 수 있으며

메시지 포맷 역시 JSON 을 이용해서 직관적으로 이해가 가능한 구조이다.

클라이언트 서버 구조 / Client - Server 구조

REST 서버는 API 를 제공하고 제공된 API 를 이용해서 비지니스 로직 처리 및 저장을 책임진다.

클라이언트는 사용자 인증이나 Context(Session, 로그인 정보) 등을 직접 관리하고 책임진다.

서버, 클라이언트가 역할이 명확하게 나눠지면서 의존성이 줄어들게 된다.

안티패턴

GET/POST 를 이용한 터널링

http://myweb/users?method=update&id=terry 이 경우가 전형적인 GET 을 이용한 터널링이다.

메서드의 실제 동작은 리소스를 업데이트하는 내용인데, HTTP PUT 을 이용하지 않고

GET 에 query param 으로 update 라고 넘겨서 수정역할을 하도록 명시했다.

제일 좋지 않은 디자인으로, HTTP 메서드 사상을 따르지 않았기 때문에 REST 도 아니고

웹 캐쉬 인프라 등도 사용이 불가능하다.

POST 를 이용한 터널링도 있는데, Create 성 오퍼레이션이 아닌데도

JSON body 에 오퍼레이션 명령을 넘기는 형태인데, 

아래 예제가 특정 사용자 정보를 가지고 오는 API 를 

POST 를 이용해서 만든 경우이다.

HTTP POST, http://myweb/users/ {      "getuser":{         "id":"terry",    } }

Self-descriptiveness 속성을 사용하지 않음

REST URI 와 메서드, 그리고 쉽게 정의된 메시지 포맷에 의해 쉽게 API 를 이해할 수 있어야한다.

HTTP Response Code 를 사용하지 않음

HTTP response code 를 따르지 않고

성공은 200, 실패는 500 과 같이 1 ~ 2개의 HTTP response code 를 사용하는 경우이다.