Hyper Text Transfer Protocol (어플리케이션 컨트롤 프로토콜(약속))
GET, POST, PUT, DELETE, OPTIONS, HEAD, TRACE, CONNECT 의 method가 존재한다.

| 의미 | CRUD | 멱등성 | 안정성 | Path Variable | Query Parameter | DataBody | |
|---|---|---|---|---|---|---|---|
| GET | 리소스 취득 | R | O | O | O | O | X |
| POST | 리소스 생성, 추가 | C | X | X | O | △ | O |
| PUT | 리소스 갱신, 생성 | C/U | O | X | O | △ | O |
| DELETE | 리소스 삭제 | D | O | X | O | O | X |
| HEAD | 헤더 데이터 취득 | - | O | O | - | - | - |
| OPTIONS | 지원하는 메소드 취득 | - | O | - | - | - | - |
| TRACE | 요청 메시지 반환 | - | O | - | - | - | - |
| CONNECT | 프록시 동작의 터널 접속으로 변경 | - | X | - | - | - | - |
💡 멱등성이란? : 서버에 여러번 요청해도 항상 결과가 같다의 표현
💡 △ 표시 : 할 수는 있지만 하지 않는 것을 추천하는 것을 △로 표시함
| Code | 의미 | 내용 |
|---|---|---|
| 1XX | 처리중 | 처리가 계속 되고 있는 상태. 클라이언트는 요청을 계속 하거나 서버의 지시에 따라서 재요청 |
| 2XX | 성공 | 요청의 성공 * PUSH : 200(수정), PUT : 201(생성) --> PUT에 한정된 내용 예시 |
| 3XX | 리다이렉트 | 다른 리소스로 리다이렉트. 해당 코드를 받았을 때는 Response의 새로운 주소로 다시 요청 |
| 4XX | 클라이언트 에러 | 클라이언트의 요청에 에러가 있는 상태. 재전송 하여도 에러가 해결되지 않는다. |
| 5XX | 서버 에러 | 서버 처리 중 에러가 발생한 상태. 재전송 시 에러가 해결 되었을 수도 있다. |
| Code | 의미 / 내용 |
|---|---|
| 200 | 성공 |
| 201 | 성공, 리소스 생성 성공 |
| 301 | 리다이렉트, 리소스가 다른 장소로 변경됨을 알림 |
| 303 | 리다이렉트, Client에서 자동으로 새로운 리소스로 요청 처리 |
| 400 | 요청 오류, 파라미터 에러 |
| 401 | 권한 없음 (인증 실패) |
| 404 | 리소스 없음 (페이지를 찾을 수 없음) |
| 500 | 서버 내부 에러 (서버 동작 처리 에러) |
| 502 | 서버->리소스 서버에 연결이 안될 때 (Bad Gateway) |
| 503 | 서비스 정지 (점검 등) |
Representational State Transfer (자원의 상태 전달)
네트워크 아키텍처 원리
| No. | 원리 | 내용 |
|---|---|---|
| 1 | Client, Server | 클라이언트와 서버가 서로 독립적으로 분리되어져 있어야 한다. |
| 2 | Stateless | 요청에 대해서 클라이언트의 상태가 서버에 저장되지 않는다. |
| 3 | 캐시 | 클라이언트는 서버의 응답을 캐시할 수 있어야 한다. 클라이언트가 캐시를 통해서 응답을 재사용할 수 있어야하며, 이를 통해 서버의 부하를 낮춘다. |
| 4 | 계층화(Layered System) | 서버와 클라이언트 사이에 방화벽, 게이트웨이, 프록시 등 다계층 형태를 구성할 수 있어야하며, 확장할 수 있어야 한다. |
| 5 | 인터페이스 일관성 | 아키텍처를 단순화 시키고 작은 단위로 분리해서 클라이언트, 서버가 독립적으로 개선될 수 있어야 한다. |
| 6 | Code On Demand(optional) | 자바 애플릿, 자바스크립트 플래시 등 특정 기능을 서버가 클라이언트에 코드를 전달하여 실행할 수 있어야 한다. |
인터페이스의 일관성이 잘 지켜졌는지에 따라서 REST를 잘 사용했는지를 판단할 수 있다.
자원 식별
→ 웹 기반의 REST에서는 리소스 접근을 URI를 사용한다.
예시)
| URI | Resource | 식별자 |
|---|---|---|
| https://foo.co.kr/user/100 | user | 100 |
메시지를 통한 리소스 조작
→ Web에서는 다양한 방식으로 데이터를 전송할 수 있다.
그 중에서는 HTML, XML, JSON, TEXT 등의 다양한 방법이 있다.
이 중에서 리소스의 타입을 알려주기 위해 header 부분에 content-type을 통해 어떠한 타입인지를 지정할 수 있다.
자기 서술적 메시지
→ 요청하는 데이터가 어떻게 처리 되어져야 하는지 충분한 데이터를 포함할 수 있어야 한다.
HTTP 기반의 REST에서는 HTTP Method와 Header의 정보로 이를 표현할 수 있다.
애플리케이션 상태에 대한 엔진으로써 하이퍼미디어
→ REST API를 개발할 때에도 단순히 Client 요청에 대한 데이터만 내리는 것이 아닌, 관련된 리소스에 대한 Link 정보까지 같이 포함되어야 한다.
*이러한 조건들을 잘 갖춘 경우 REST Ful하다고 말하며, 이를 REST API라고 부른다.
Uniform Resource Identifier (리소스 식별자)
특정 사이트, 특정 쇼핑 목록, 동영상 목록 등 모든 정보에 접근할 수 있는 정보
한 가지 리소스가 있다고 가정했을 경우 이곳에 접근할 수 있는 주소는 여러개가 존재할 수 있지만 한개의 주소가 여러개의 리소스를 접근할 수 없다.
URL은 URI의 하위 개념이다./는 계층 관계를 나타낼 때 사용한다./는 포함하지 않는다.-은 URI가독성을 높이는데에 사용한다._는 사용하지 않는다.명사에 단수형보다는 복수형을 사용해야 한다. 컬렉션에 대한 표현은 복수로 사용컨트롤러 이름으로는 동사나 동사구를 사용한다.| OSI 7 Layer | TCP/IP |
|---|---|
| 7. 응용계층 | 4. 응용 계층 |
| 6. 표현 계층 | 4. 응용 계층 |
| 5. 세션 계층 | 4. 응용 계층 |
| 4. 전송 계층 | 3. 전송 계층 |
| 3. 네트워크 계층 | 2. 인터넷 계층 |
| 2. 데이터 계층 | 1. 네트워크 접속 |
| 1. 물리 계층 | 1. 네트워크 접속 |
Hyper Text Markup Language (하이퍼미디어 포맷)
XML을 바탕으로한 범용 문서 포맷
Chrome, Safari, Explorer에서 사용자가 알아보기 쉬운 형태로 표현