8주차 - 1) RESTful API 및 EC2 무중단 배포

Ⅰ. 핵심 키워드

1. REST / RESTful

1) HTTP 메서드의 용도

① Get

• 서버로부터 정보를 요청하는 메서드이다. 클라이언트가 서버에게 데이터를 요청할 때 주로 사용된다.
• GET 요청은 요청할 리소스의 주소에 매개변수를 포함하여 전송된다. 즉, 요청하는 데이터를 URL의 일부인 쿼리 문자열(query string)로 포함시켜 전송한다.
• 요청한 데이터가 URL에 노출되므로 보안에 취약하다.
• 요청할 수 있는 데이터의 크기에 제한이 있다.
• 요청이 캐시될 수 있어 반복적인 요청의 경우 캐시된 응답을 사용할 수 있다.

② Post

• 서버로 데이터를 제출하는 메서드이다. 클라이언트가 POST 요청을 통해 서버로 데이터를 전송하면, 서버는 해당 데이터를 처리하고 응답을 반환한다.
• POST 요청은 요청 본문(request body)에 데이터를 담아 전송한다.
• 데이터가 request body에 담겨 전송되므로 요청한 데이터가 URL에 노출되지 않는다. (GET보다 보안적으로 더 안전하다.)
• 요청할 수 있는 데이터의 크기에 제한이 없어 대용량 데이터의 전송에 적합하다.
• 요청이 캐시되지 않는다. 매번 새로운 요청으로 인식한다

GET은 주로 데이터의 조회나 검색에 사용되고, POST는 데이터의 생성이나 변경에 사용된다.

③ PATCH

• 서버에게 리소스의 일부를 수정하도록 요청하는 메서드로, 말그대로 리소스의 일부를 변경하고자 할 때 사용된다.
• PATCH 요청은 request body에 변경할 데이터를 담아 서버에 전송된다. 이 메서드는 주로 업데이트나 부분적인 수정이 필요한 경우에 사용된다.
• 리소스의 부분적인 수정이 가능하므로, 전체 리소스를 수정하는 것보다 효율적이다.
• 일부 서버에서는 PATCH메서드를 지원하지 않는 경우도 있다.

④ PUT

• 서버에게 리소스를 생성하거나 수정하도록 요청하는 메서드이다. 클라이언트는 PUT 요청을 통해 리소스를 서버에 제출한다.
• PUT 요청은 request body에 전체 리소스 데이터를 담아 서버에 전송한다. 따라서, PUT 요청은 주로 리소스의 생성이나 전체적인 수정이 필요한 경우에 사용된다.
• 이미 존재하는 리소스를 수정하는 용도로 사용된다는 점은 PATCH와 유사하지만, 리소스의 전체적인 수정이 이루어진다는 점에서 차이가 있다.
• 클라이언트가 리소스의 식별자를 정확하게 알고 있어야 한다. 식별자가 없으면 새로운 리소스를 생성하게 된다.

⑤ DELETE

• 서버로부터 리소스를 삭제하도록 요청하는 메서드이다. 클라이언트가 DELETE 요청을 보내면 서버는 해당 리소스를 삭제하고 응답을 반환한다.
• request body를 사용하지 않는다. 대부분의 DELETE 요청은 리소스 식별자를 URL에 포함시켜 전송하는데, 이러한 점은 GET과 유사하다.
• 서버는 요청된 리소스를 삭제하고, 삭제가 성공했는지에 대한 응답을 반환한다.
• PUT과 마찬가지로 클라이언트가 리소스의 식별자를 정확하게 알고 있어야 한다.

2) Restful 설계

① URI Rules

• 마지막에 ‘/’를 포함하지 않는다.
  ex) http://api.test.com/users
• 언더바(_)대신 대시(-)를 사용한다.
  ex) http://api.test.com/users/post-commnets
• 소문자를 사용한다. (camelCase도 사용금지)
  ex) http://api.test.com/users/post-commnets
• 메서드에만 동사가 존재하고 URL에는 동사를 포함하지 않는다.
  ex) DELETE http://api.test.com/users/1/posts/1
• 컨트롤 자원을 의미하는 URL은 예외적으로 동사를 허용한다.
  ex) http://api.test.com//posts/duplicate

② Content-Location

• POST요청은 대부분 idempotent하지 않다.
• idempotent란, GET과 PUT처럼 언제나 같은 결과로 응답되는 것을 의미한다. POST로 같은 이름의 user를 계속해서 추가하면 사용자가 실제로 계속해서 추가되는 것을 생각해보면 이해가 쉬울 것이다.
• 반면, Get이나 Put은 idemptent하다.

③ Post, Get, Put(Patch), Delete의 4가지 메서드는 필수적으로 제공

④ Collection과 Document

• 컬렉션과 도큐멘트는 모두 리소스에 속하며 URI로 표현된다.
  ex) http://www.chrome.com/universities/inha/students/1218
• 위 URI를 보면 universities, students는 컬렉션이고, inha, 1218은 도큐먼트이다. 직관성을 높이기 위해 컬렉션은 주로 복수로, 도큐멘트는 단수로 표현한다.

⑤ 자주 쓰이는 HTTP status 코드

• 성공 응답에 대해 반드시 2XX를 사용한다.
  
• 실패응답은 4XX를 사용한다.
  
• 리다이렉션 또는 서버에러에는 각각 3XX와 5XX를 사용하되, API서버단에서 5XX 에러가 발생해선 안된다.

  500번대 에러는 API server를 서빙하는 웹서버(apache나 nginx 등)가 오류일 때 사용하는 에러지, API에서 발생하는 예외를 처리하는 에러가 아니다. 500번대 에러는 통상적으로 서비스 장애를 의미하는데, API level에서 이 에러가 나온다는 것은 잘못 설계했다는 의미가 되어버린다. 적어도 API level에선 500번대 에러가 발생하지 않도록 모든 예외를 처리해야 한다.
  

2. Path Variable

Path Variable은 API에서 URL 경로에 포함된 가변 데이터를 나타낸다. URL의 일부로, 리소스의 식별이나 필터링에 사용된다. 아래의 예시를 보자.

ex) https://example.com/users/{id}

여기서 ‘{id}’가 바로 Path Variable이다. 이 부분은 실제 user의 고유한 식별자를 나타내는 값을 가진다. 이를 활용하면 특정 user를 조회하는 작업을 수행할 수도 있다. 이 때 사용형식은 보통 아래와 같을 것이다.

ex) https://example.com/users/12

클라이언트가 요청을 보낼 때 경로 변수에 해당하는 값을 전달하여 서버가 요청을 처리하고 응답을 반환한다. 경로 변수를 사용하면 동일한 URL 패턴을 유지하면서 다양한 리소스에 접근할 수 있다. 이는 RESTful API에서 유연하고 효율적인 리소스 관리를 가능하게 한다.

3. Query Parameter

Query Parameter는 RESTful API에서 URL에 추가적인 매개변수를 전달하는 데 사용되는 방법이다. 쿼리 파라미터는 URL의 끝에 ?로 시작하여, key=value 형식으로 지정된다. 여러 개의 쿼리 파라미터가 필요한 경우에는 &로 구분한다. 아래의 예시를 보자.

ex) https://example.com/search?query=keyword&page=1

여기서 query와 page가 쿼리 파라미터에 해당하는데, query는 검색어를, page는 페이지 번호를 나타내는 값으로 쓰였다. 클라이언트는 요청을 보낼 때 이러한 쿼리 파라미터를 지정하여 서버에게 추가 정보를 전달할 수 있다.

쿼리 파라미터는 선택적이며, 필요한 경우에만 사용된다. 서버는 쿼리 파라미터를 사용하여 요청을 처리하고, 클라이언트에게 맞는 응답을 반환한다. 쿼리 파라미터는 리소스 필터링, 정렬, 페이징 등과 같은 기능을 구현하는 데 자주 사용된다.

쿼리 파라미터는 URL에 추가되므로, 요청의 목적과 의도를 알기 쉽게 표현할 수 있다. 또한, 다양한 쿼리 파라미터 조합을 통해 다양한 검색 및 필터링 옵션을 제공할 수 있다.

ex) https://example.com/search?category=books&sort=price&order=asc
→ category는 책 카테고리, sort는 가격을 기준으로 정렬하고, order는 오름차순으로 정렬하라는 의미이다.

4. Path Variable과 Query Parameter의 용도

1) Path Variable

① 리소스 식별

• 경로 변수는 리소스를 고유하게 식별하는 데 사용된다.
• 예를 들어, /users/{id}와 같은 URL 패턴에서 {id}는 사용자의 고유한 식별자 값을 나타낸다.
• 즉, 경로 변수를 사용하여 특정 사용자를 조회하거나 수정하는 등의 작업을 수행할 수 있다.

② 계층적 리소스

• 경로 변수는 계층적인 리소스 구조를 표현하는 데 유용하다.
• 예를 들어, /categories/{categoryId}/products/{productId}와 같은 URL 패턴에서 {categoryId}와 {productId}는 각각 카테고리와 제품의 식별자 값을 나타낸다.
• 이를 통해 특정 카테고리에 속한 제품을 조회하는 등의 작업을 수행할 수 있다.

2) Query Parameter

① 필터링 및 정렬

• 쿼리 파라미터는 리소스를 필터링하거나 정렬하는 데 사용된다.
• 예를 들어, /products?category=electronics&brand=samsung과 같은 URL에서 category와 brand는 제품을 카테고리와 브랜드로 필터링하는 데 사용된다.

② 페이징

• 쿼리 파라미터는 페이지네이션을 구현하는 데 사용된다.
• 예를 들어, /products?page=2&limit=10과 같은 URL에서 page는 페이지 번호를, limit은 페이지당 아이템 수를 지정한다.
• 이를 통해 페이지네이션된 제품 목록을 요청할 수 있다.
• 아래의 그림과 같은 것을 페이지네이션이라 부른다.
  

③ 선택적 매개변수

• 쿼리 파라미터는 선택적인 매개변수를 전달하는 데 사용된다.
• 예를 들어, /search?keyword=apple&category=fruits와 같은 URL에서 keyword와 category는 검색어와 카테고리로 선택적인 검색을 수행하는 데 사용된다.

5. 프록시 서버

프록시 서버(Proxy Server)는 클라이언트와 다른 서버 사이에서 중개자 역할을 하는 서버이다. 클라이언트가 웹 서버에 직접 요청을 보내는 대신, 프록시 서버를 통해 요청을 전달하고 응답을 받는다. 이는 네트워크 통신의 효율성, 보안, 캐싱 등을 개선하기 위해서이다. 프록시의 기능 및 이점은 아래와 같다.

① 캐싱

• 프록시 서버는 클라이언트의 요청에 대한 응답을 캐싱하여 동일한 요청에 대해 중복된 네트워크 트래픽을 줄인다.
• 클라이언트가 동일한 리소스를 요청할 때, 프록시 서버는 캐시된 응답을 반환하여 더 빠른 응답 속도를 제공할 수 있다.

② 보안

• 프록시 서버는 클라이언트와 서버 사이에서 중개자 역할을 수행하기 때문에, 클라이언트의 실제 IP 주소를 숨기고 서버에 대한 보안을 강화할 수 있다.
• 외부에서 직접적인 접근을 막고, 필요한 경우 보안 정책을 적용할 수 있다.

  ※ 리버스 프록시
  리버스 프록시(Reverse Proxy)는 컴퓨터 네트워크에서 사용되는 프록시 서버의 한 유형이다. 일반적으로 프록시 서버는 클라이언트와 서버 사이에서 클라이언트의 요청을 서버로 전달하는 반면, 리버스 프록시는 서버 측에 위치하여 서버로 들어오는 요청을 받아 서버에 전달한다.
  즉, 클라이언트의 정보를 서버에서 숨기는 것이 아니라, 서버의 정보를 클라이언트에게 숨기는 것이다. 나중에 웹 서버나 웹 어플리케이션 서버를 배우면서 자세히 다룰 내용이다.

③ 필터링 및 접근 제어

• 프록시 서버는 요청과 응답을 검사하여 특정 콘텐츠나 도메인에 대한 필터링, 액세스 제어 정책을 적용할 수 있다.
• 예를 들어, 웹 필터링을 통해 악성 사이트 차단, 콘텐츠 필터링, 액세스 제한 등을 수행할 수 있다.

④ 로드 밸런싱

• 프록시 서버는 여러 개의 백엔드 서버로 요청을 분산하여 로드 밸런싱을 수행할 수 있다.
• 클라이언트의 요청을 가장 적절한 서버로 전달하여 성능을 향상시킨다.

6. JPA 템플릿 폴더 구조

1) src

① DTO

• DTO(Domain Transfer Object 또는 Data Transfer Object)는 데이터의 전송을 위해 사용되는 객체이다. 일반적으로 비즈니스 로직을 포함하지 않고 데이터만을 저장하고 전달하기 위해 사용된다.
• DTO는 데이터의 구조를 정의하는 클래스로, 여러 개의 속성(데이터 필드)을 가질 수 있다. 주로 데이터베이스의 엔티티(Entity) 객체와 데이터를 주고받을 때 사용되며, 데이터베이스의 특정 테이블과 일치하는 구조를 가진다.
• DTO는 데이터 전송을 위한 편리한 컨테이너로 사용되며, 데이터의 가공 및 전달을 단순화하고 유지 보수성을 높일 수 있다.
• DTO는 필요한 데이터를 추출하거나 가공하여 전달하기 위해 사용될 수 있다. 즉, 여러 개의 엔티티 객체에서 필요한 데이터만을 선택하여 DTO에 담을 수 있다.
• 클라이언트에 반환될 데이터를 표현하기 위해 DTO를 사용할 수 있다. 클라이언트의 요청에 대한 응답으로 DTO를 사용하여 필요한 데이터를 선택하고 반환한다.

② Controller

• Controller는 MVC (Model-View-Controller) 패턴에서 "컨트롤러(Controller)" 컴포넌트를 나타낸다. 컨트롤러는 사용자의 요청을 받고, 이에 대한 처리를 수행하며, 그 결과를 적절한 응답으로 반환하는 역할을 담당한다.
• 컨트롤러는 클라이언트의 요청을 분석하고, 필요한 비즈니스 로직이나 서비스를 호출하여 요청을 처리한다. 그 후, 처리된 결과를 사용자에게 응답으로 반환한다.
• 컨트롤러는 비즈니스 로직의 처리 결과에 따라 적절한 응답을 생성한다. 응답은 주로 클라이언트에게 전송될 HTML, JSON, XML 등의 형태로 반환된다.
• 컨트롤러는 처리된 결과를 표시할 뷰(View)를 선택하고, 필요한 데이터를 뷰에 전달한다. 뷰는 사용자에게 결과를 표시하는 역할을 수행한다.

③ Repository

• 데이터베이스나 데이터 저장소와 관련된 작업을 추상화하고 캡슐화하는 객체이다. 주로 데이터베이스에 접근하고 데이터를 조작하는 기능을 제공한다.

• 데이터 액세스 계층(Data Access Layer)에서 사용되며, 비즈니스 로직과 데이터베이스 사이의 상호작용을 관리한다.

• 데이터베이스에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행합니다. 데이터를 생성, 읽기, 업데이트, 삭제하는 메서드를 제공하여 데이터베이스와의 상호작용을 추상화한다.

• 데이터를 조회하고 필요한 변환, 가공 등의 작업을 수행한다. 데이터베이스로부터 조회된 데이터를 비즈니스 로직에 맞게 가공하여 반환한다.

• 일반적으로 Repository는 DAO 패턴과 연관되어 사용된다.

  ※ DAO
  Data Access Object의 약자로, 데이터 액세스 객체를 의미한다. 즉, 데이터베이스나 다른 영구 저장소에 접근하여 데이터를 조작하과 관리하는 객체를 말한다.

• Repository는 비즈니스 로직에서 데이터베이스에 직접 액세스하는 코드를 분리하여 관리하고, 데이터 액세스의 추상화와 유연성을 제공한다.

④ Service

• 비즈니스 로직을 처리하는 역할을 담당하는 컴포넌트이다. 비즈니스 로직은 애플리케이션의 핵심적인 로직이며, 데이터의 가공, 검증, 트랜잭션 관리 등을 담당한다.
• 컨트롤러(Controller)와 데이터 액세스 계층(Repository 또는 DAO) 사이에서 중개자 역할을 수행한다.
• 도메인 객체의 생성, 업데이트, 삭제 등을 처리하며, 비즈니스 규칙을 적용한다.
• 액세스 제어 및 보안 규칙을 적용하여 인증 및 권한 관리를 수행할 수 있다. 사용자의 인증 상태를 확인하고, 권한에 따라 액세스를 제한하거나 특정 작업을 실행할 수 있다.

2) config

config는 "Configuration"의 약자로, 애플리케이션의 설정 정보를 포함하고 있는 파일, 클래스, 또는 모듈을 가리킨다. config는 애플리케이션의 동작 방식을 지정하고 조정하는 데 사용된다.
① 환경 설정

• 애플리케이션의 환경 설정을 관리한다. 이는 데이터베이스 연결 정보 등과 같은 애플리케이션의 동작에 필요한 매개변수들을 포함한다.
• 이러한 설정은 애플리케이션의 특정 환경(로컬, 개발, 테스트, 운영 등)에 따라 다르게 지정될 수 있다.

② 의존성 주입 설정

• 애플리케이션에서 사용되는 서비스, 컴포넌트, 라이브러리 등의 의존성을 구성하는 데 사용된다.
• 의존성 주입 프레임워크를 사용하는 경우, Config 파일에서 의존성을 설정하고 주입할 수 있다.

③ 로깅 설정

• 로깅 라이브러리의 설정을 관리한다. 로깅 수준, 로그 저장 위치, 로그 형식 등을 구성할 수 있다.
• 이를 통해 애플리케이션의 로깅 동작을 제어하고, 디버깅 및 모니터링에 유용한 정보를 기록할 수 있다.

④ 외부 서비스 연동 설정

• 애플리케이션이 외부 서비스와 통신하는 데 필요한 설정을 관리한다.
• 예를 들어, 이메일 서비스, 메시징 큐, 파일 시스템 경로 등과의 연동을 설정할 수 있다.

⑤ 보안 설정

• 애플리케이션의 보안 설정을 관리한다.
• 인증 방식, 암호화 알고리즘, 접근 제어 규칙 등을 구성할 수 있다.

실습에서 사용했던 .yml파일이 config에 해당한다.

7. Entity

엔티티(Entity) 파일은 객체 지향 프로그래밍에서 데이터베이스의 테이블과 매핑되는 도메인 객체를 정의하는 파일이다. 엔티티는 애플리케이션의 도메인 모델을 나타내며, 데이터베이스와의 상호작용을 담당하는 객체이다. 주로 객체-관계 매핑(Object-Relational Mapping, ORM) 기술을 사용하는 프레임워크 또는 라이브러리에서 사용되는 개념이며, 대표적인 예로는 Java의 JPA(Java Persistence API)가 있다.

엔티티 파일은 주로 클래스로 표현되며, 클래스의 속성은 데이터베이스 테이블의 컬럼과 매핑된다. 엔티티 파일의 특징은 아래와 같다.

① 속성(Attributes)

• 엔티티는 데이터베이스 테이블의 컬럼과 일치하는 필드를 가지고 있다.
• 예를 들어, 사용자(User) 엔티티의 필드로는 아이디, 이름, 이메일 등이 있을 수 있다.

② 관계(Relationships)

• 엔티티는 다른 엔티티와의 관계를 정의할 수 있다.
• 예를 들어, 사용자(User) 엔티티와 주문(Order) 엔티티 간에 일대다 관계가 있을 수 있다.

③ 메서드(Methods)

• 엔티티는 데이터베이스와의 상호작용을 위한 CRUD(Create, Read, Update, Delete) 작업을 수행하는 메서드를 가질 수 있다.
• 이러한 메서드는 데이터베이스로부터 데이터를 읽고 저장하며, 엔티티의 상태를 변경하는 역할을 한다.

④ 어노테이션(Annotations)

• 엔티티와 데이터베이스 테이블 간의 매핑을 위해 어노테이션을 사용한다.
• 이 애노테이션을 통해 엔티티의 속성과 데이터베이스 테이블의 컬럼, 관계 등을 명시적으로 정의할 수 있다.