흔적 노트

1. 마이크로서비스에 대해 설명해보세요.

하나의 어플리케이션을 이루는 서비스들을 기능 단위로 쪼개서 구축하는 것을 말합니다.

기존의 모놀로식 아키텍처의 문제점은, 하나의 서비스에 트래픽이 몰리면 그 쪽만 확장하면 되는데 이 단위 별로의 확장이 불가능하고, 일부 서비스의 오류가 전체 서비스에 영향을 준다는 것이었습니다.

마이크로 서비스를 채택하면, 일부 서비스가 장애가 있으면 해당 서비스만 내려가고, 나머지엔 영향이 없으며 시즌별로 트래픽이 몰리는 서비스쪽만 확장이 가능하다는 장점이 있습니다.

그리고 각 서비스마다 더 적절한 언어나 기술을 사용할 수 있다는 점도 있습니다.

단점은 모놀로식 아키텍처에 비해 구축 난이도, 개발 및 테스트가 어렵다는 단점이 있습니다.

1. Stomp가 뭔가요?

Stomp는 Simple Text Oriented Messaging Protocol의 약자로,

Websocket 위에서 동작하는 텍스트 기반 메세징 프로토콜입니다.

Stomp는 Publish-Subscribe 매커니즘을 제공합니다.

Broker를 통해 다른 사용자들에게 메시지를 보내거나 서버가 특정 작업을 수행하도록 메세지를 보낼 수 있습니다.

2. WebSocket 대신 Stomp를 사용하는 이유가 뭔가요?

각 커넥션마다 WebSocketHandler를 구현하는 것보다 Controller Annotation이 적용된 객체를 이용해 조직적으로 관리를 할 수 있습니다. ( 메세지를 Controller 객체의 MessageMapping Annotation으로 라우팅시킬 수 있습니다. )

Stomp의 Destination(URI 경로)를 기반으로 Spring Security를 적용해 메세지를 보호할 수 있습니다.

정리

Stomp는 Websocket 위에서 동작하는 텍스트 기반의 메세지 전송 프로토콜입니다.

메세지를 Controller 어노테이션이 적용된 객체를 이용해 조직적으로 관리할 수 있으며 Spring Security를 적용해 메세지를 보호할 수 있습니다.

간단하게만 정리해보았는데 좀 더 자세하게 알아야 할 것 같습니다 ㅠ 추후에 정리 한번 다시 하겠습니다

참조:

https://velog.io/@koseungbin/WebSocket#stomp

1. CORS에 대해서 설명해보세요.

CORS란, (= Cross Origin Resource Sharing )

서로 다른 도메인간에 자원을 공유하는 것을 의미하며 기본적으로 차단되어있습니다.

Origin이란 출처를 의미하며 Protocol + Host + Port 를 합친 것을 말합니다.

Origin이 같으면 CORS 에러는 발생하지 않습니다.

예를 들어 아래 개발 환경은 포트가 다르기때문에, Origin이 다른 것으로 판단되어 자원 요청 시 CORS 에러가 발생합니다.

http://localhost:8080

http://localhost:8000 

2. CORS 에러 해결 방법은 뭔가요?

서버에서 응답 헤더에 특정 헤더를 포함하는 방식으로 해결할 수 있습니다.

Access-Control-Allow-Origin: 특정 브라우저가 리소스에 접근이 가능하도록 허용합니다.

Access-Control-Allow-Method: 특정 HTTP Method만 리소스에 접근이 가능하도록 허용합니다.

Access-Control-Expose-Headers: 자바스크립트에서 헤더에 접근할 수 있도록 허용합니다.

credentials: 쿠키 등의 인증 정보를 전달할 수 있습니다.

# 정리

CORS란 서로 다른 Origin간에 자원을 공유하는 것을 말하며 기본적으로 브라우저간에 차단되어있습니다.

Origin이란 출처를 말하며, Protocol + Host + Port 를 합친 것을 의미합니다.

CORS 에러는 서버에서 응답 헤더에 특정 헤더를 포함하는 방식으로 해결할 수 있습니다.

예를 들어 Access-Control-Allow-Origin을 통해 특정 브라우저가 리소스에 접근이 가능하도록 허용할 수 있습니다.

감사합니다.

참조:

https://beomy.github.io/tech/browser/cors/

안녕하세요. 오늘은 REST 에 대해서 알아보겠습니다.

REST란, (=REpresentational State Transfer)

자원을 URI를 통해 명시하고, Method를 통해 해당 자원에 대한 행위를 정의하는 것을 의미합니다.

쉽게 말해서 Resource를 HTTP Method를 통해 처리하도록 설계된 아키텍처를 말합니다.

아래 표를 보면 이해가 쉽게 됩니다.

REST는 아래와 같은 구성 요소로 이루어져있습니다.

자원: URI

행위: HTTP Method

표현: Message(Json, XML 등을 이용한 표현)

REST를 사용하는 이유는 HTTP 표준을 기반으로 구현되며 메세지가 의도하는 바를 쉽게 파악할 수 있다는 점입니다.

그리고 다양한 브라우저와 디바이스에서도 통신을 해야하며 어플리케이션을 분리 및 통합하기 위해 사용됩니다.

REST API란,

REST 기반으로 서비스 API를 구현한 것을 말합니다.

API란 라이브러리 제공을 통해 프로그램간에 특정 기능을 호출할 수 있는 명세를 의미합니다.

REST API를 사용하는 이유는 REST는 HTTP 표준을 기반으로 구현하므로,  HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있습니다.

REST API의 설계 규칙은 다음과 같습니다.

1. URI로 자원을 표현한다.

2. Method로 자원에 대한 행위를 표현한다.

3. 슬래시(/)는 계층 관계를 나타낸다.

4. URL 마지막에 / 사용을 금지한다.

5. 언더바(_) 대신 하이픈(-)을 사용한다.

6. URI 경로에는 소문자를 사용한다.

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

REST에 대해서 알아보았습니다.

Microservice에서도 보통 Rest API로 통신하기때문에 설계를 한 번 해보는 것이 좋은 것 같습니다.

참조:

https://velog.io/@stampid/REST-API%EC%99%80-RESTful-API

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

안녕하세요.

오늘은 웹 통신에 사용되는 프로토콜인 HTTP에 대해서 알아보겠습니다.

HTTP이란, ( = Hyper Text Transfer Protocol )

1. 웹에서 데이터를 주고받기 위해 사용되는 프로토콜입니다.

2. 상태가 없는 스테이트리스(Stateless) 프로토콜입니다.

3. TCP/IP 프로토콜 위에서 동작하며 80번 포트를 사용합니다.

- 여기서 TCP/IP 프로토콜이란, 인터넷에서 사용되는 표준 프로토콜입니다. 서로 다른 시스템을 가진 기기들을 연결하여 데이터를 전송하기 위해 사용됩니다.

[ HTTP Request와 Response ]

Client가 Server로 데이터를 요청하는 것을 HTTP Request, 

Server가 Client로부터 받은 요청에 따라 이에 대한 응답을  HTTP Response라고 합니다.

요청을 보내는 쪽을 Client, 요청을 받고 이에 대한 응답(데이터)를 반환하는 쪽을 서버라고 합니다.

[ HTTP의 구조 ] 

HTTP Request의 구조는 크게 3부분으로 구성됩니다.

• Start line
• Headers
• Body

아래 명령어를 통해 HTTP 요청을 보내보았을 때, 다음과 같은 HTTP Request와 Response를 확인할 수 있었습니다.

curl -v http://localhost:8000/test

> GET /test?a=1 HTTP/1.1
> Host: localhost:8000
> User-Agent: curl/7.55.1
> Accept: */*
>

여기서 아래 부분을 HTTP Request의 startline이라고 합니다.

> GET /test?a=1 HTTP/1.1

Startline은 HTTP Method + Request Target + HTTP Version 으로 이루어져있습니다.

HTTP Method란,

해당 Request의 자원에 대한 행위를 정의하며 종류로는 GET, POST, PUT, DELETE 등이 있습니다.

예를 들어 GET은 자원을 얻는 것, POST는 등록을 목적으로 사용합니다.

Request Target이란,

해당 Request의 목표 URI를 의미합니다. 여기서 URI란 인터넷의 자원을 칭하는 통합 고유 자원 식별자를 말합니다.

그리고 아래 부분을 HTTP Request Headers라고 합니다.

> Host: localhost:8000
> User-Agent: curl/7.55.1
> Accept: */*

Header는 Request에 대한 추가 정보를 담고있습니다. 자주 사용되는 header의 정보는 다음과 같습니다.

Host: 요청이 전송되는 Target의 Host URL을 말합니다.

User-Agent: 요청을 보낸 클라이언트의 정보를 말합니다.

Accept: 해당 타입의 Response를 보내달라고 요청합니다.

Content-Type: Request의 body 타입을 말합니다.

Content-Length: 메세지 Body의 길이를 말합니다.

Authorization: JWT 같은 인증 토큰을 서버로 보낼 때 사용하는 헤더입니다.

그리고 지금은 비어있지만, 해당 Request의 내용이 위치하는 Body가 있습니다.

아래는 HTTP Response의 구조입니다.

< HTTP/1.1 200
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< Content-Type: text/plain;charset=UTF-8
< Content-Length: 9
< Date: Sun, 05 Sep 2021 07:26:31 GMT
<
HTTP test* Connection #0 to host localhost left intact

구조는 거의 동일하지만, 정보가 조금씩 다릅니다.

# StartLine

HTTP Version + Status Code + Status Text 로 이루어져있습니다.

Status Code: 응답 코드로, 200은 성공을 의미합니다.

Status Text: 응답 코드에 대한 메세지로, 200이면 OK가 담겨있습니다.

# Header

Date: 응답 일시

Content-type: 응답 데이터의 타입

HTTP에 대해서, 그리고 구조에 대해서 알아보았습니다.

참조:

https://programmer93.tistory.com/60