이번 스프린트는 간단하게 서버와 상호작용하는 것을 배웁니다.
실제 코드 구현은 다음 챕터에서 다루고, 이번 챕터는 이론을 간.단하게 정리합니다 :)
HTTP
HTTP
서버와 클라이언트가 주로 HTML 등의 문서를 주고받는 데 사용하는 프로토콜입니다.
아래의 응답 / 요청 과정을 봅시다! 가장 먼저 HTTP/1이 연결되고,
위에서 아래로 GET -> Response -> GET - Response -> 를 반복하면서 진행합니다.
HTTP의 특징은 2가지만 확실히 기억하면 됩니다.
- Stateless : 무상태성, HTTP는 이전 요청 또는 다음 요청을 기억하지 않습니다.
- Connectionless : 비연속성, 연결 상태를 유지하지 않습니다.
극단적인 예로는...다음과 같습니다.
철수: 밥먹자 -> 영미: 뭐먹을래 -> 철수: 고기 -> 영미: 고기가 뭐?
URI
HTTP 요청은 URI을 통해 할 수 있습니다.
주소창을 통해 하는 요청은 전부 GET Request 입니다.
HTTP REQUEST METHOD
요청 방법으로는 4가지가 있습니다. 많이들 들어보셨을텐데요,
1.GET : 특정 리소스를 가져오도록 요청.
2.POST : 데이터를 서버로 제출하는 용도
3.PUT : POST와 비슷하지만, 연속적인 요청에도 같은 효과를 가져욤.
4.DELETE : 리소스의 삭제를 요청.
STATUS CODE
상태 코드는 대표적인 몇 가지만 기억해도 괜찮습니다. 나머지는 발생 시 찾아보면 되니까요.
- 200 : 요청 성공
- 304 : 요청에 대한 응답이 수정되지 않음.
- 403 : 접근 권한 없음.
- 404 : 요청 리소스를 사용할 수 없음.
- 500 : 서버가 처리할 수 없는 요청.
RESTFUL API
API 디자인 시, HTTP 프로토콜을 의도에 맞게 사용하도록 정의된 아키텍쳐 스타일입니다.
상당히 세부적인 내용이 많으므로, 여기서는 간단하게 알아봅시다.
다음은 RESTFUL의 구성입니다.
- 자원(RESOURCE) - URI
- 행위(Verb) - HTTP METHOD
- 표현(Representations)
REST의 특징은 무엇이 있을까요?
- Uniform (유니폼 인터페이스) : URI로 지정한 리소스에 대한 조작 아키텍처 스타일을 말합니다.
- Stateless (무상태성) : 작업을 위한 상태정보를 따로 저장하고 관리하지 않습니다.
- Cacheable (캐시 가능) : HTTP가 가진 캐싱 기능이 적용 가능합니다.
- Self-descriptiveness (자체 표현 구조)
- Client - Server 구조 : C / S 의 역할이 명확해지고 서로간 의존성이 줄어들게 됩니다.
- 계층형 구조 : 다중 계층으로 구성될 수 있습니다.
REST API 설계 시 가장 중요한 항목은 다음의 2가지입니다.
이것만 기억해도 될 정도로 중요합니다.
- URI는 정보의 자원을 표현해야 합니다.
- 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현합니다.
Client - Server Communication
클라이언트와 서버는 프로토콜이라는 정해진 규약에 따라 메시지를 교환합니다.
클라이언트는 서버가 어떤식으로 요청을 처리하는지에 대해선 구체적으로 알 필요없고,
API를 바탕으로 원격 서버에 요청을 하고, 응답에 대해 적절한 형태로 화면에 표시합니다.
이제 다음 챕터에서 실제 코드로 상호작용을 해봅시다 🤫🤫🤫
