HTTP
-HyperText Transfer Protocol
-하이퍼텍스트(링크) 문서를 교환하기 위해 어떠한 형식으로 서로 통신을 하자고 규정해 놓은 protocol(통신 규약)
-프론트앤드 서버와 클라이언트간, 백앤드와 프론트앤드 서버간의 통신에 사용된다.(백앤드-백앤드서버 간에도 사용됨)
-TCP/IP 기반으로 되어있다.
통신방식
-request/response 구조
-stateless(상태를 저장하지 않는다)이다.
-요청이 오면 그에 응답할 뿐 다른 요청/응답에 대해서는 알지 못한다.
-데이터가 필요할 때는 쿠키나 세션을 사용한다.
request 구조(start line, headers, body)
1.start line
-
Method
-의도한 액션을 정의하는 부분
-get, post, put, delete 등이 있다.
-주로get,post가 쓰인다. -
request target
-해당 request가 전송되는 경로 uri
ex) /login. -
version
-1.0, 1.1, 2.0 등이 있는데 표준버전은1.1
2.headers
-request에 대한 추가 정보를 담고 있다.
host- 요청이 전송되는 target의 host url
user-agent- 요청을 보내는 클라이언트(웹브라우저)에 대한 정보
accept- 해당 요청이 받을 수 있는 응답 타입
connection- 요청이 끝난 후 클라이언트와 서버가 계속 네트워크 연결을 유지 할 것인지 끊을 것인지 지시하는 부분
content-type- 요청이 보내는 메시지 타입 ex) application/json
content-length- 메시지 body의 길이
-key-value 값으로 되어있다.(:사용)
ex) HOST(key) : google.com(value)
-크게 3부분으로 나뉜다.(general hearders, request headers, entity headers)
3.body
-request의 실제 메세지 내용
-body가 없는 request도 많다.
response 구조(status line, headers, body)
1.status line
-http 버전, status code(응답 상태를 나타내는 코드 ex)200), status text(응답 상태를 설명해주는 부분 ex)Not Found)
HTTP/1.1 404 Not Found
2.headers
-request의 headers와 동일
-user-agent 대신 server 헤더가 사용된다.
3.body
-request의 body와 동일하다.
HTTP Methods
GET
-어떠한 데이터를 서버로 부터 받아 올때 주로 사용
-생성, 수정, 삭제 없이 받아오기만 할 때 사용
-request에 body없이 보내는 경우가 많다.
POST / PUT
-데이터를 생성, 수정, 삭제할 때 사용되는 Method
-대부분 request body가 포함돼서 보내진다.
-최근 몇년 사이에 POST를 주로 사용한다.
DELETE
-특정 데이터를 삭제 요청 할 때 쓰인다.
-POST에 밀려서 잘 사용하지 않는다.
OPTIONS
-주로 요청 URI에서 어떤 Method를 요청 가능한가를 알고 싶을 때 먼저 사용한다.
HTTP Status Code
200 OK
-문제없이 잘 실행되었을 때 보내는 코드
301 Moved Permanently
-해당 URI가 다른 주소로 바뀌었을 때 보내는 코드
400 Bad Request
-해당 요청이 잘못된 요청일 때 보내는 코드
ex) 전화번호를 보내야 하는데 text가 보내졌을 때
401 Unauthorized
-유저가 해당 요청을 진행 할려면 먼저 로그인을 하거나 회원 가입을 하거나 등등이 필요하다는것을 나타내려 할때 쓰이는 코드
403 Forbidden
-유저가 해당 요청에 대한 권한이 없다는 뜻
404 Not Found
-요청된 URI가 존재 하지 않는다는 뜻
500 Internal Server Error
-서버에서 에러가 났을 때 사용
REST API
Representational State Transfer API의 약자로 자원(RESOURCE)URI, 행위(Verb)HTTP METHOD, 표현(Representations)으로 이루어져 있다.
주로 GET, POST만 사용한다.
REST의 특징
1. Uniform (유니폼 인터페이스)
Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다.
2. Stateless (무상태성)
데이터를 요청 / 응답만 할 뿐 세션 정보나 쿠키 정보를 별도로 저장하고 관리하지 않는다. 그래서 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않아 구현이 단순해진다.
3. Cacheable (캐시 가능)
HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다. 따라서 HTTP가 가진 캐싱 기능이 적용 가능합니다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.
4. Self-descriptiveness (자체 표현 구조)
REST API 메시지만 보고도 목적을 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다.
5. Client - Server 구조
서버와 클라이언트 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어든다.
6. 계층형 구조
REST 서버는 다중 계층으로 구성될 수 있고 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 두고, PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있다.
REST API 설계
- URI는 정보의 자원을 표현해야한다. 이것은
명사로 표현한다. 동사가 들어가서는 안된다. - 자원에 대한 행위는
HTTP Method(GET, POST, PUT, DELETE)를 사용한다.
GET users/show/1 (X)
GET users/1 (O)GET users/delete/1 (X)
DELETE users/1 (O)-
슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다.
http://restapi.example.com/houses/apartments -
URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
-
URI 가독성을 높이기 위해 하이픈(-)을 사용한다.
불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높일 수 있다. -
가독성을 위해 밑줄(_), 긴 단어, 대문자는 사용하지 않는다.
-
파일 확장자는 URI에 포함시키지 않는다.
http://restapi.example.com/members/soccer/345/photo.jpg (X)
