WEB. World Wide Web. WWW. W3
: 인터넷에 연결된 컴퓨터를 통해 사람들이 정보를 공유할 수 있는 전세계적인 정보 공간
웹은 HTTP, URI, HTML이 3가지 요소로 이루어져 있다.
HyperText Transfer Protocol
어플리케이션을 제어하는 프로토콜로, 데이터를 주고 받을 때 교환되는 데이터 형식에 대한 상호 합의이다.
RFC 2616에서 규정한 웹에서 데이터를 주고 받을 때 사용하는 프로토콜로, 하이퍼텍스트 전송용 프로토콜이라는 이름과는 다르게 HTML, XML, JSON, 이미지, 음성파일, 영상파일, JS, PDF 등 컴퓨터에서 다룰 수 있는 것은 모두 전송할 수 있다.
클라이언트 쪽에서는 HTTP 통신을 통해 URI로 서버에 데이터를 요청하는 메시지를 작성, 전송하고 응답을 대기한다. 서버에서는 항상 요청을 대기하고 있으며, 요청을 수신하면 이를 해석하고, 담당한 애플리케이션의 로직을 통해 요청을 처리한 후 응답 메시지를 송신한다. 이 응답은 HTML이나 JSON의 형태를 취한다. 클라이언트가 이 응답을 수신하면 응답을 해석하고 데이터를 처리 및 표시하여 통신이 이루어지게 된다.
HTTP에는 GET, POST, PUT, DELETE 말고도 OPTIONS, HEAD, TRACE, CONNECT 등의 다양한 메서드가 존재한다.
메서드 | 의미 | CRUD | 멱등성 | 안정성 | Path Variable | Query Parameter | DataBody |
---|---|---|---|---|---|---|---|
GET | 리소스 취득 | R(read) | O | O | O | O | X |
POST | 리소스 생성, 추가, 수정 | C(create) | X | X | O | △ | O |
PUT | 리소스 수정, 생성 | C, U(update) | O | X | O | △ | O |
DELETE | 리소스 삭제 | D(delete) | O | X | O | O | X |
HEAD | 헤더 데이터 취득 | - | O | O | - | - | - |
OPTIONS | 지원하는 메서드 취득 | - | O | - | - | - | - |
TRACE | 요청 메시지 반환 | - | O | - | - | - | - |
CONNECT | 프록시 동작의 터널 접속으로 변경 | - | X | - | - | - | - |
* 멱등성: 서버에 여러 번 요청을 해도 항상 결과가 같을 때 멱등하다고 한다.
- PUT은 리소스가 없으면 생성을 하고, 있으면 보낸 내용으로 수정을 하기 때문에 멱등하다.
- DELETE는 리소스가 있으면 삭제하고, 없으면 없는 상태를 유지하기 때문에 멱등하다.
* 안정성: 특정한 리소스에 요청을 했을 때 데이터에 대한 변화가 없을 때 안정성을 보장한다고 한다.
* Path Variable: 주소로 정보를 전달할 수 있음
* Query Parameter: Query Parameter를 통해 특정 리소스를 찾기 위해 필터를 적용할 수 있음
* DataBody: 요청 body에 데이터를 실을 수 있는지 여부. 일부 framework에서는 get방식에도 body를 실을 수 있지만 프로토콜에 어긋난다.
* △: 할 수 있지만 권장x
코드 | 의미 | 내용 |
---|---|---|
1XX | 처리중 | 처리가 계속되고 있는 상태 - 클라이언트는 요청을 계속 하거나, 서버의 지시에 따라 재요청 |
2XX | 성공 | 성공적인 요청, 성공적인 응답 |
3XX | 리다이렉트 | 다른 리소스로 리다이렉트 - 해당 코드와 함께 Response로 받은 새 주소로 요청 |
4XX | 클라이언트 에러 | 클라이언트측에서 에러가 발생한 상태 |
5XX | 서버 에러 | 서버측에서 에러가 발생한 상태 |
* PUT 메서드에 한정하여,
200: 데이터가 성공적으로 수정됨,
201: 데이터가 성공적으로 생성됨
Uniform Resource Identifier
리소스 식별자로, 특정 사이트에 들어가거나, 동영상 목록을 볼 때 등 웹 상에 있는 모든 정보에 접근할 수 있는 주소이다.
한 가지 리소스가 있다고 하면 이 리소스에 접근할 수 있는 URI는 여러 개가 존재할 수 있지만, 한 개의 주소가 여러 개의 리소스에 접근할 수는 없다. 특정 리소스에 대해서는 유니크한 주소만 존재하게 된다.
HyperText Markup Language
XML을 바탕으로 한 번역 문서 포맷으로, 범용 문서 포맷이다. 서버에 요청을 보내면, HTML로 구성된 문자열을 받아 크롬, 사파이, 엣지 등의 브라우저에서 사용자가 알아보기 쉬운 형태로 표현한다.
Representational State Transfer
네트워크 아키텍처 원리로, 자원의 상태를 전달하기 위해서는 아래 조건들을 충족해야 한다.
1. Client & Server
: 클라이언트와 서버가 서로 독립적으로 분리되어 있어야 한다.
2. Stateless
: 클라이언트의 상태를 서버에 저장하지 않는다. +클라이언트가 2번 연속으로 같은 요청을 보냈다고 하더라도 서버는 각각의 두 요청을 모두 별개의 요청으로 인식한다.
3. Cache
클라이언트는 서버의 응답을 캐시로 저장해 재사용할 수 있어야 한다.
+캐시를 사용하면 서버의 부하를 낮출 수 있다. JS같은 경우에는 처음 요청을 보냈을 때 받은 데이터를 캐싱하여, 버전을 확인했을 때 동일한 버전인 경우에는 캐시된 데이터를 사용하기도 한다.
++최근에는 서버의 사양이 높아지기도 했고, 실시간으로 데이터가 바뀌는 경우가 잦아졌기 때문에 캐시를 사용하지 않는 경우도 있다.
4. Layered System
서버와 클라이언트 사이에는 반드시 방화벽, 게이트웨이, 프록시 등 다양한 층이 존재해 계층화된 구조를 가지고 있어야 한다. 또, 언제든지 요구사항에 맞춰 확장할 수 있는 형태로 구성되어야 한다.
5. Interface Specification
인터페이스가 일관성을 가져야 한다. 서버의 변화가 클라이언트에게 영향을 끼쳐서는 안된다는 것으로(반대도 마찬가지), 아키텍처를 단순화하여 작은 단위로 쪼개 클라이언트와 서버가 독립적으로 개선될 수 있어야 한다.
영어를 직역한 부분이라 잘 와닿지 않는 부분이다. 이는 결국 서버와 클라이언트 사이에 잘 구성된 인터페이스가 존재해, 각 측에 변경이 있다고 하더라도 통신에 영향을 주어서는 안된다는 말이다.
6. Code on Demand(OPTIONAL)
자바 애플릿이나 자바스크립트 플래시 등의 특정 기능이 클라이언트로 전달했을 때 실행할 수 있는 형태로 개발되어야 한다는 원리이다.
인터페이스의 일관성 여부로 REST가 잘 구현되었는지를 판단할 수 있다.
1. 자원 식별이 가능
: 웹 기반의 REST에서는 URI를 사용해 리소스에 접근한다.
https://www.test.co.kr/user/1 이라는 주소가 있다면, 리소스는 user고 식별자는 1이 된다.
2. 메시지를 통한 리소스 조작이 가능
: 웹에서는 HTML, JSON, XML, TEXT 등 다양한 방법으로 데이터를 전송할 수 있기 때문에, 리소스의 타입을 header 부분에 명시해야 한다.
3. 자기 서술적 메시지 작성 가능
: HTTP Method와 Header로 요청하는 데이터의 처리 방침에 대해 충분한 정보를 전달해야 한다.
4. 애플리케이션 상태에 대한 엔진으로 하이퍼미디어를 사용
: 단순히 클라이언트의 요청에 대한 데이터를 전송하는 것만이 아니라, 관련된 리소스에 대한 링크까지 포함해야 한다.
이러한 조건을 갖춘 경우에 RESTful하다고 할 수 있다.
URI와 URL는 차이를 가진다. URI는 인터넷에서 특정 자원을 나타내는 주소값으로, 해당 값은 유일하다.
URL은 Uniform Resource Locator로, 인터넷 상의 자원이나 특정 파일이 어디에 위치하는지 식별하는 주소이다.
URI: https://www.test.co.kr/resource/sample/1
URL: https://www.test.co.kr/sample1.pdf
URL은 URI의 하위 개념이다.
URI 설계 원칙(RFX-3986)
- 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다.
- URI 마지막 문자로 /는 포함하지 않는다.
- 하이픈은 URI 가독성을 높이는 데 사용한다. (띄어쓰기 대체)
- 언더바(_)는 사용하지 않는다.
- 소문자만 사용한다.
- 파일 확장자는 URI에 포함하지 않는다. (ex: .jsp)
- 프로그래밍 언어에 의존적인 확장자를 사용하지 않는다. (시스템 취약점이 드러나 공격받을 수 있다. ex: .do)
- 구현에 의존적인 경로를 사용하지 않는다. (해킹에 취약해질 수 있다. ex: .../servlet/...)
- 세션 ID를 포함하지 않는다.
- 프로그래밍 언어의 Method 명을 사용하지 않는다.
- 명사를 쓸 때는 단수형보다는 복수형을 사용하는 것이 좋다. 컬렉션이면 복수로 쓴다.
- 컨트롤러의 이름으로는 동사나 동사 구를 사용한다.
- 경로 중 변하는 부분은 변수로 대체한다.
- CRUD 기능을 나타내는 단어는 URI에 사용하지 않는다.
- URI 쿼리 파라미터 디자인:
- 쿼리로 컬렉션의 결과를 필터링할 수 있다.
- 쿼리로 컬렉션의 결과를 페이지로 구분해 나타낼 수 있다.
- API나 클라이언트 캐발자 포탈 서브 도메인 등은 일관성있게 만들어야 한다.
Spring Boot
1. Spring에서 어플리케이션 개발에 필수인 요소들만 모아두었다.
2. 간단한 설정으로 개발 및 커스텀이 가능하다.
3. 간단하고 빠르게 어플리케이션 실행 및 배포가 가능하다.
4. 대규모 프로젝트에 필요한 보안, 모니터링 등의 기능을 제공한다.
5. 오랜 시간 사용되었기 때문에 안정적인 운영이 가능하다.
6. Spring의 불편한 점이 개선되었다. (ex: XML 설정 제거)
Spring Boot의 build 툴은 Maven과 Gradle 두 가지가 있는데, 주로 Gradle을 사용하는 추세이다.
서블릿 컨테이너는 Tomcat, Jetty, Undertow 등이 있다. 디폴트는 Tomcat이다.