1) HTTP
2-1. HTTP란?
hypertext transfer protocol의 약자인데,
쉽게 말하면 서버와 클라이언트 사이에서 어떻게 메시지를 교환할 지를 정해놓은 규칙이라고 보면 됩니다.
- 80번 포트 사용
- Request와 Response로 구성되어 있음.
처음에는 단순히 문서를 교환하기 위해 만들어진 오래된 규칙이었는데 웹이 계속 발전하다 보니 문서 이외에 이미지나 영상도 교환하게 되면서 HTTP의 단점이 드러나게 되었습니다.
2-2. HTTP의 기본 속성 (한계)
-
STATELESS : 상태정보가 저장되지 않음
-
일회성
-
연결된 액션을 하더라도 기본적으로 프로토콜 상에서는 독자적인 request들의 연속에 불과함.
(ex, 로그인을 해서 중고나라 카페에 입장해서 작성한다)
=> 이것을 연결시키기 위해 쿠키라는 이름의 브라우저의 특정 정보를 남겨서 세션에 저장해 유저를 트래킹하는 방식이 들어오게됨.
-
-
CONNECTLESS : 서버에 요청을 하고 응답을 한 이후에 연결은 끊어짐.
- 하나의 독자적인 액션 = 독자적인 REQUEST
- 유저 인터페이스가 뚝뚝끊기는 느낌을 줌 (다른것을 하려고하면 페이지가 끊김.)
2) URL
2-1. URL이란?
URL (uniform resource locator)
어떤 서비스를 만들어서 클라이언트에게 배포할 때, 우리의 데이터를 클라이언트가 찾을 수 있도록 하는 파일위치.
-
URL의 구성
Scheme + Host + Port + Path
http:// localhost : 3000 / posts / 3
2-2. URL의 문제점
다 좋은데 PATH를 만드는 방식이 중구난방이었음.
-
GET, POST로 CRUD를 전부 다 커버하려다보니 url 패턴이 꼬이는 경우가 많아짐.
-
즉, 각 api를 활용할 때마다 명세를 상세히 봐야한다는 불편함이 생김.
그래서 누군가가 REST API라는 방식을 제안했습니다.
2-3. REST API란?
결국에는 모든 로직이 CRUD니까 얘들만 표준화시키면 된다!
-
GET, POST, PATCH, DELETE <-> R, C, U, D
(put이랑 patch가 둘다 update고 약간 다르다고 하긴 하던데..)
이렇게 각 행동에 대한 메서드들을 대응시킨 방식을 REST API라고 함.
-
즉, CRUD마다 URL pattern을 고정시켜서 어떤 api call을 보내든 유추할 수 있는 것.
2-4. REST API를 구성하는 방법
-
url은 정보의 자원을 표현해야 한다.
-
자원 : 특정한 데이터
(ex 유저 1번의 3번째 코멘트)
-
-
자원에 대한 행위는 HTTP Method로 표현한다.
-
즉 URL은 데이터만 표현해야함. 동사를 표현하지 말자!
ex 포스트를 수정하는 메서드
- URL = posts/1/update (X)
- URL = posts/1 & HTTP Method = PUT (O)
-
-
http Method path controller, action object POST /geocoder geocoders#create geocoder를 생성 GET /geocoder geocoders#show 하나뿐인 geocoder 리소스를 표시 GET /geocoder/edit geocoders#edit geocoder 수정용 HTML 양식을 반환 PATCH/PUT /geocoder geocoders#update 하나뿐인 geocoder 리소스를 갱신 DELETE /geocoder geocoders#destroy geocoder 리소스를 삭제 GET /geocoder/new geocoders#new geocoder 작성용 양식을 반환
2-5. 요약
우리가 rest api를 사용하기 위해서는
- 파일의 위치에 따라서 url을 만든다.
- 동사(C, R, U, D)에 따라 HTTP method를 구분한다.