230823 TIL : HTTP, REST, URI, 스프링 부트란

 

📌 230823 TIL: HTTP, REST, URI, 스프링 부트란

 

---

HTTP(Hyper Text Transfer Protocol): 어플리케이션 컨트롤하는 프로토콜

GET/POST/PUT/DLEETE/OPTIONS/HEAD/TRACE/CONNECT

 

URI(Uniform Resource Indentifier): 리소스 식별자

특정 사이트, 특정 쇼핑 목록, 동영상 목록 모든 정보에 접근할 수 있는 정보

 

HTML(Hyper Text Transfer Marker Language): 하이퍼 미디어 포맷.

xml을 바탕으로 한 범용 문서 포맷. 이를 이용하여 크롬, 사파리 등에서 사용자가 알아보기 쉬운 형태로 표현

 

📝 HTTP : RFC2616에서 Web에서 데이터를 주고 받는 프로토콜

이름은 하이퍼 텍스트 전송용 프로토콜로 정의되어 있지만, HTML, XML, JSON, PDF, Video, Image 등 컴퓨터에서 다룰수 있는 것은 모두 전송할 수 있음. 
TCP를 기반으로 한 REST 특징을 모두 구현하고 있는 WEB 기반의 프로토콜.

 

📝 HTTP 종류 :

* 멱등성 : 연산을 여러번 적용해도 결과가 달라지지 않는 성질 (Post는 서버에 데이터를 요청할 때마다 값이 달라지기 때문에 멱등하지 않음. PUT은 서버에 데이터가 없으면 생성하고 있으면 갱신하기 때문에 멱등함)

* 안정성 : 데이터의 안정성

	의미	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	-	-	-	-

 

📝 Response 응답 코드:

1XX: 처리가 계속 되고 있는 상태. 서버의 지시에 따라 재요청
2XX: 요청의 성공.
[200: 성공, 201: PUT에 한하여 데이터가 생성 성공]
3XX: 다른 리소스로 리다이렉트. 해당코드 받았을 때에는 response의 새로운 주소로 다시 요청
[301: 리소스가 다른 장소로 변경됨을 알림. 303: 클라이언트에서 자동으로 새로운 리소스로 요청 처리]
4XX: 클라이언트 에러. 재전송해도 해결 안됨.
[400: 요청 오류, 401: 권한 없음. 404: 리소스 없음. (페이지 찾을 수 없음)]
5XX: 서버 에러. 재전송시 해결 될 수도 있음. 
[500: 서버 내부 에러(서버 동장 처리 에러), 503: 서비스 정지(점검 등)]

 

---

 

📝 REST 규칙 (Representational State Transfer, 자원의 상태 전달) 

1) client, server: 클라이언트, 서버가 독립적으로 분리되어 있어야한다.

2) Stateless : 요청에 대해서 클라이언트의 상태가 서버에 저장하지 않아야한다. 

3) 캐시: 클라이언트는 서버의 응답을 캐시할 수 있어야한다. 클라이언트가 캐시를 통해서 응답을 재사용할 수 있어야하며, 이를 통해 서버의 부하를 낮춘다. 

4) 계층화(Layer System): 서버와 클라이언트 사이에 방화벽, 게이트웨이, 프록시 등 다계층 형태를 구성할 수 있어야하며, 확장 가능해야한다. 

5) 인터페이스 일관성: 아키텍처를 단순화시키고 작은 단위로 분리하면서 클라이언트, 서버가 독립적으로 개선될 수 있어야 한다.

6) Code On Demand(optional): 자바 애플릿, 자바 스크립트 플래시 등 특정 기능을 서버가 클라이언트에 코드를 전달하여 실행할 수 있어야한다. 

 

 

📝 REST를 잘 사용했는지 판단하는 법: 인터페이스의 일관성 지켰는가.

아래의 조건을 잘 갖춘것이 REST ful하다고 말하며, REST API라고 한다.

 

1) 자원 식별 : url에 자원이 식별되는가. 

2) 메시지를 통한 리소스 조작 : header의 content-type에 json, xml, html 같은 방식이 잘 정의되어 있는가.

3) 자기 서술적 메시지 : GET,POST 같은 정보를 header에 잘 표시해야함. 

4) 애플리케이션 상태에 대한 엔진으로서 하이퍼미디어: 단순히 클라이언트 요청에 대한 데이터만 내리는 것이 아닌 리소스에 대한 link 정보까지 같이 포함되어야한다. 

 

---

 

📝 URI 와 URL 의 차이 

1) URI (Uniform Resource Identifier) 

인터넷에서 특정 자원을 나타내는 주솟값. 해당값은 유일하다. 정확히 지칭 X. HTTP에 따라 정해짐.

ex) http:// www.foo.co.kr/resource/sample/1 

resource : sample1.pdf, sample.doc

 

2) URL(Uniform Resource Locator)

인터넷 상에서 자원, 특정 파일이 어디에 위치하는지 식별하는 주소. URI의 하위개념이다. 정확하게 지칭.

ex) http:// www.foo.co.kr/resource/sample.pdf 

 

 

📝 URI 설계 원칙 

- 슬래시 (/) 는 계층 관계를 표현한다. 

- 마지막에 슬래시 포함하지 않는다.

- 하이픈(-)의 사용은 가독성을 높임 (띄어쓰기 대체 용도)

- 밑줄(_) 은 사용하지 않는다. 

- 경로는 소문자가 적합하다..

- 파일의 확장자는 URI에 포함하지 않는다. 

- 프로그래밍 언어에 의존적인 확장자를 사용하지 않는다.

- 구현에 의존적인 경로를 사용하지 않는다.

- 세션 ID 포함하지 않는다.

- 프로그래밍 언어의 method 명 사용하지 않는다. (강제성 X)

- 명사에 단수형보단 복수형. 컬렉션에 대한 표현은 복수로 사용한다.

- 컨트롤러 이름으로는 동사나 동사구를 사용한다. (ex. re-order)

- 경로 부분 중 변하는 부분은 유일한 값으로 대체한다.

- CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.

- 쿼리부분은 컬렉션 결과에 대해서 필터링한다. 

- 쿼리 부분은 결과를 페이지로 구분하여 나타낸다.

- API에 있어 서브 도메인은 일관성 있게 사용해야 한다.

- 클라이언트 개발자 포탈 서브 도메인은 일관성있게 만든다.  

---

📝 데이터의 전달 

 

데이터의 전달은 항상 문자열을 보낸다고 생각한다. 

데이터의 전달은 OSI 7 Layer의 애플리케이션 레이어부터 물리계층까지를 통해 만들어져 TCP/IP 통신을 통해 목적지로 전달된다. 

 

---

📝 스프링 부트 란?

스프링 부트는 단순히 실행되며, 프로덕션 제품 수준의 스프링 기반 어플리케이션을 쉽게 만들 수 있다. 

스프링 부트 어플리케이션에는 스프링의 구성이 거의 필요하지 않다. 

스프링 부트 java-jar 로 시작하는 java 어플리케이션을 만들 수 있다. 

 

목표

- 스프링 개발에 빠르고 광범위하게 적용할 수 있는 환경

- 기본값 설정이 있지만 설정을 바꿀 수 있다.

- 대규모 프로젝트에 공통적인 비 기능 제공(보안, 모니터링)

- XML 구성 요구사항이 전혀 없다. 

 

장점

어플리케이션 개발에 필수 요소들만 모아두었다. 

오랜 경험에서 나오는 안정적인 운영이 가능하다. 

스프링에서 불편한 설정이 없어졌다. (XML 같은)

간단한 설정으로 개발 및 커스텀이 가능하다.