Http protocol

http는 요청 메소드를 정의하여 리소스에 수행하길 원하는 행동을 나타낸다.

- Request method

GET - 특정 리소스의 표시를 요청한다. GET을 사용하는 요청은 오직 데이터를 받기만 함
HEAD - GET메소드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않는다
POST - 특정 리소스에 엔티티를 제출할 때 쓰인다. 이는 종종 서버의 상태의 변화나 부작용을 일으킨다
PUT - 목적 리소스 현재 표시를 요청 payload로 바꾼다
DELETE - 특정 리소스를 삭제한다
CONNECT - 목적 리소스로 식별되는 서버로의 터널을 맺는다I’m
OPTIONS - 목적 리소스의 통신을 설정하는데 쓰인다
TRACE - 목적 리소스의 경로를 따라 메시지 loop-back 테스트를 한다
PATCH - 리소스의 부분만을 수정하는데 쓰인다

- Response의 종류

<HTTP/2>

HTTP/2는 이전에 애플리케이션 내에서 수행되던 상당수의 HTTP/1.1 임시 방편을 실행취소하고 이러한 문제를 전송 계층 내에서 해결할 수 있도록 함으로써 애플리케이션을 더 빠르고, 단순하고, 강력하게 만들어준다.

HTTP/2의 주요 목표는 전체 요청을 통해 지연 시간을 줄이고, 응답 다중화를 지원하며, HTTP 헤더 필드의 효율적 압축을 통해 프로토콜 오버헤드를 최소화하고, 요청 우선순위 지정을 추가하며, 서버 푸시를 지원하는 것이다.

HTTP/2는 HTTP의 애플리케이션 의미 체계를 어떤 식으로도 수정하지 않습니다. 모든 핵심 개념(예: HTTP 메서드, 상태 코드, URI 및 헤더 필드)은 그대로 유지됩니다. 그 대신 HTTP/2는 클라이언트와 서버 간에 데이터 서식(프레임)이 지정되는 방식과 데이터가 전송되는 방식을 수정한다. 클라이언트와 서버는 전체 프로세스를 관리하며 애플리케이션의 모든 복잡성을 새 프레이밍 계층 내에 숨긴다. 따라서 기존의 모든 애플리케이션을 수정 없이 전달할 수 있다.

HTTP/1.X와 차이점

• 텍스트가 아닌 바이너리입니다.
• 순서 지정 및 차단 대신 완전히 다중화됩니다.
• 병렬 처리를 위해 하나의 연결을 사용할 수 있습니다.
• 헤더 압축을 사용하여 오버 헤드를 줄입니다.
• 이를 통해 서버 푸시는 브라우저 캐시에 사전에 응답을 추가 할 수 있습니다.

<REST(RESTFUL) API>

REST - Representational State Transfe의 약자, 자원을 URI로 표시하고 해당 자원의 상태를 주고받는 것

REST의 구성요소
1) 자원 : URI
2) 행위 : HTTP METHOD
3) 표현

즉, REST는 URI를 통해 자원을 표시하고 HTTP METHOD를 이용하여 해당 자원의 행위를 정해주며 그 결과를 받는 것

REST기반의 규칙들을 지켜서 설계된 API

#설계규칙
1. URI는 정보의 자원을 표현해야한다.
자원의 이름은 동사보다는 명사를 사용한다.
URI는 자원을 표현하는데 중점을 두어야 하기 때문에 행위에 대한 표현이 들어가면 안된다. (URI에 HTTP METHOD와 행위에대한 동사 표현이 들어가면 안된다.)

GET /users/321

2. 자원에 대한 행위는 HTTP METHOD로 표현한다. (GET, POST, PUT DELETE)
   URI에 자원의 행위에 대한 표현이 들어가지 않는 대신 HTTP METHOD를 통해 대신한다.

GET /users/321 321 ID를 가진 유저 정보를 가져오기
DELETE /users/321 321 ID를 가진 유저 정보를 삭제하기
POST /users 유저를 생성하기

3. 슬래시 (/)는 계층 관계를 나타내는데 사용한다.

   http://restapi.test.com/users/rooms
   http://restapi.test.com/users/board

4. URI 마지막은 슬래시(/)를 사용하면 안된다

   http://restapi.test.com/users/rooms/ [X]
   http://restapi.test.com/users/rooms  [O]

5. 하이픈 (-)은 URI의 가독성을 높이는데 사용한다.불가피하게 긴 URI를 사용하게 될 경우 하이픈을 이용하여 가독성을 높인다.

6. 언더바(_) 혹은 밑줄은 URI에 사용하지 않는다.밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 한다.그래서 대신 언더바를 사용하지 않고 하이픈을 이용한다.

7. URI는 경로에는 소문자가 적합하다.URI 경로에는 대문자 사용을 피해야한다.대소문자에 따라 각자 다른 리소스로 인식하기 때문이다.RFC3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문이다.

8. 파일 확장자는 URI에 포함하지 않는다.REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.Accept header를 사용한다.

9. 리소스 간의 관계를 표현하는 방법

   GET : /users/{userid}/devices

목적 : 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것

- Restful 하지 못한 경우
- CRUD 기능을 전부 POST METHOD로만 처리하는 API
- URI에 자원과 ID외 정보가 들어가는 경우

PUT /users/update-nickname [X]
PUT /users/:id/nickname [O]

[https://velog.io/@stampid/REST-API와-RESTful-API](https://velog.io/@stampid/REST-API%EC%99%80-RESTful-API)