UMC 6주차

Simple·2021년 11월 25일

UMC 1기 Server

목록 보기

6/9

1. 학습 목표

RESTful한 설계방식에 대해 이해한다.
Server to Server 통신에 대해 이해한다.
템플릿 구조에 대해 이해하고 실습해본다.

2. 6주차 수업 후기

💡 6주차 수업 듣고 느낀점 이야기, 각자 진행상황 공유

템플릿 내부 로직이해와 코드에 대한 이해로만 2~3일은 썼다.....
예외처리,,,,,,,,,,,

3. 실습

실습 체크리스트

❗️ 이번 주차는 개념적인 내용보다는 REST API를 최대한 많이, 꼼꼼하게 설계&구현해보면서 템플릿에 익숙해지는 게 핵심입니다. 이번 과제 API 최소 개수는 10개이지만 가능한만큼 최대로 많이 만들어오시면 됩니다.

프록시 서버 설정
서버 무중단 배포
지난 주 과제때 설계/구현한 API에 RESTful원칙을 적용하고 템플릿을 사용해서 구현하기
API 추가 구현하기
HTTP Method를 모두 사용해보기
Path Variable, Query String, Body를 모두 사용해보기
형식적/논리적 Validation 추가하기
API Sheet 작성

🔥 트러블 슈팅(실패한 경험도 성장을 위한 경험!)

트러블 슈팅 양식 [ 문제 원인 ] java JDK 버전이 안맞았다.

[ 해결 방안 ] File > Project Structure 에서 버전 맞춰주기

[ 참고 자료 ]

트러블 슈팅 양식 [문제 원인] 프로젝트를 열었는데 빌드가 안된다. [해결 방안] 시간이 지나서 알아서 제외가 된건지, 수동으로 해줘야 하는지 아직 의문,,

[참고 자료]

트러블 슈팅 양식 [문제 원인]@PathVariable 적용을 해야할걸 @RequestParam(required = false)를 적용했다. [해결 방안] @PathVariable 로 수정 [참고 자료]

4. 핵심 키워드

REST/RESTful

REST(REpresentational State Transfer)란?

REST의 정의 "REpresentational State Transfer" 의 약자로, 자원을 이름(자원의 표현)으로 구분해 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미합니다. 즉, 자원(resource)의 표현(representation)에 의한 상태 전달을 뜻합니다.
- 자원 : 해당 소프트웨어가 관리하는 모든 것 ( 문서, 그림, 데이터, 해당 소프트웨어 자체 등 )
- 표현 : 그 자원을 표현하기 위한 이름 ( DB의 학생 정보가 자원이면, 'students'를 자원의 표현으로 정함 )
- 상태 전달 : 데이터가 요청되는 시점에 자원의 상태를 전달한다. ( JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적 )
  
  REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에,
  
  웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일입니다.
  
  REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나입니다.
REST의 개념 어떤 자원에 대해 CRUD(Create, Read, Update, Delete) 연산을 수행하기 위해 URI(Resource)로 GET, POST 등의 방식(Method)을 사용하여 요청을 보내며, 요청을 위한 자원은 특정한 형태(Representation of Resource)로 표현됩니다.

URI 와 URL의 차이점?URL은 Uniform Resource Locator로 인터넷 상 자원의 위치를 의미합니다.반면 URI는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로,URI는 URL을 포함하게 됩니다. URI가 URL보다 포괄적인 범위라고 할 수 있습니다.

REST의 구성요소1. 자원(Resource) - URI

- 모든 자원에는 고유한 ID가 존재하고, 이 자원은 Server에 존재합니다.
- 자원을 구별하는 ID는 '/exgroups/:exgroup_id'와 같은 HTTP URI 입니다.
- Client는 URI를 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청합니다.

2. 행위(Verb) - Method

- HTTP 프로토콜의 Method를 사용합니다.
- HTTP 프로토콜은 GET, POST, PUT, PATCH, DELETE의 Method를 제공합니다. ( CRUD )

3. 표현 ( Representation of Resource )

- Client와 Server가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS 등이 있습니다.
- JSON, XML을 통해 데이터를 주고 받는 것이 일반적입니다.

REST의 특징 1. Server-Client (서버-클라이언트 구조)
- 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 됩니다.
  - REST Server는 API를 제공하고 비즈니스 로직 처리 및 저장을 책임지고,
  - Client는 사용자 인증이나 context( 세션, 로그인 정보 ) 등을 직접 관리하고 책임집니다.
  - 역할을 확실히 구분시킴으로써 서로 간의 의존성을 줄입니다.2. Stateless (무상태)
- HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖습니다.
- Client의 context를 Server에 저장하지 않습니다.
  - 즉, 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해집니다.
- Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리합니다.
  - 각 API 서버는 Client의 요청만을 단순 처리합니다.
  - 즉, 이전 요청이 다음 요청의 처리에 연관되어서는 안됩니다. ( DB에 의해 바뀌는 것은 허용 )
  - Server의 처리 방식에 일관성을 부여하기 때문에 서비스의 자유도가 높아집니다.3. Cacheable (캐시 처리 기능)
- 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있습니다.
  - 즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있습니다.
  - HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용해 캐싱을 구현합니다.
- 대량의 요청을 효율적으로 처리할 수 있습니다.4. Layered System (계층 구조)
- Client는 REST API Server만 호출합니다.
- REST Server는 다중 계층으로 구성될 수 있습니다.
  - 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있습니다.
  - Proxy, Gateway와 같은 네트워크 기반의 중간매체를 사용할 수 있습니다.
  - 하지만 Client는 Server와 직접 통신하는지, 중간 서버와 통신하는지는 알 수 없습니다.5. Uniform Interface (인터페이스 일관성)
- URI로 지정한 Resource에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미합니다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하며, Loosely Coupling(느슨한 결함) 형태를 갖습니다.
  - 즉, 특정 언어나 기술에 종속되지 않음6. Self-Descriptiveness (자체 표현)
- 요청 메시지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있습니다.

REST API란?

### **API( Application Programming Interface)란?**
 
 - API는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻합니다.
 
### **REST API의 정의**
 
 - REST의 특징을 기반으로 서비스 API를 구현한 것
 - 최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 어플리케이션을 여러 개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 기업 대부분은 REST API를 제공합니다.
 
### **REST API의 특징**
 
 - REST API의 가장 큰 특징은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능한 것 입니다.
 
### **REST API 디자인 가이드**
 
 REST API 설계 시 가장 중요한 항목은 다음의 2가지로 요약합니다.
 
 - **첫 번째,** URI는 정보의 자원을 표현해야 한다.
 - **두 번째,** 자원에 대한 행위는 HTTP Method(GET, POST, PUT, PATCH, DELETE)로 표현한다.
     - 행위(Method)는 URI에 포함하지 않는다.
 
### **REST API의 설계 규칙**
 
**1. URI는 명사를 사용한다.(리소스명은 동사가 아닌 명사를 사용해야 한다.)**
 
**1-1. 아래와 같은 동사를 사용하지 말 것**
 
 - /getAllUsers
 - /getUserById
 - /createNewUser
 - /updateUser
 - /deleteUser
 
**2. 슬래시( / )로 계층 관계를 표현한다.**
 
**3. URI 마지막 문자로 슬래시 ( / )를 포함하지 않는다.**
 
**4. 밑줄( _ )을 사용하지 않고, 하이픈( - )을 사용한다.**
 
**5. URI는 소문자로만 구성한다.**
 
**6. HTTP 응답 상태 코드 사용**
 
 - **클라이언트는 해당 요청에 대한 실패, 처리완료 또는 잘못된 요청 등에 대한 피드백을 받아야 한다.**
 
 **[HTTP 상태 코드 정리](https://dev-coco.tistory.com/98)**
 
 **7. 파일확장자는 URI에 포함하지 않는다.**
 
 **Ex) [http://dev-coco.tistory.com/restapi/220/photo.jpg](http://dev-coco.tistory.com/manage/restapi/220/photo.jpg) (X)**

REST API와 RESTful API의 차이

차이
그래서 REST API와 RESTful API의 차이는 뭘까?
RESTful은 REST의 설계 규칙을 잘 지켜서 설계된 API를 RESTful한 API라고 합니다. 즉, REST의 원리를 잘 따르는 시스템을 RESTful이란 용어로 지칭됩니다. RESTful하게 만든 API는 요청을 보내는 주소만으로도 어떤 것을 요청 하는지 파악이 가능합니다. 예를들어, https://school.com/grade 의 주소는 학교의 학년들을 목록으로 받는 요청일 것입니다.
```
{
"results" : [
    {"idx": 1, "name": "1학년"},
    {"idx": 2, "name": "2학년"},
    {"idx": 3, "name": "3학년"}
    ]
}
```
https://school.com/grade/2 이렇게 idx, 고유번호가 붙는다면, idx가 2인 학년의 정보가 올 겁니다. 그리고 https://school.com/grade/2/students 의 students가 붙으면 2반 학생들의 정보를 받아올 수 있습니다.
```
{
"results" : [
    {"idx": 1, "name": "홍길동", "gender": "male"},
    {"idx": 2, "name": "성춘향", "gender": "female"},
    {"idx": 3, "name": "전우치", "gender": "male"},
    {"idx": 4, "name": "나기백", "gender": "male"},
    ...
    ]
}
```
또, https://school.com/grade/2/students/15 라는 idx를 붙이면 그 학생들 중 15의 idx를 가진 학생의 정보가 오겠죠. 혹은 https://school.com/grade/2/students?gender=male 와 같이 조건을 붙여서 남학생들의 정보만 받아올 수도 있습니다. 한 페이지당 10명의 데이터를 받아오는 거라면 이런식으로도 표현이 가능합니다. https://school.com/grade/2/students?page=2&count=10
```
{
"results" : [
    {"idx": 11, "name": "신짱구", "gender": "male"},
    {"idx": 12, "name": "김지우", "gender": "female"},
    {"idx": 13, "name": "김화석", "gender": "male"},
    {"idx": 14, "name": "박수쳐", "gender": "male"},
    ...
    ]
}
```
[ youtube - REST API가 뭔가요? 中·· ] 이렇게 RESTful API는 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것을 목적으로. 만약, 성능이 중요한 상황이라면 굳이 RESTful 한 API를 구현할 필요는 없습니다.

HTTP Method
HTTP Response Code 의미 412 -Precondition failed (전체 조건 실패) 414 -Request-URI too long (요청 URL 길이가 긴 경우임) 500 -Internal server error (내부 서버 오류) 501 -Not implemented (웹 서버가 처리할 수 없음) 503 -Service unnailable (서비스 제공 불가) 504 -Gateway timeout (게이트웨이 시간 초과) 505 -HTTP version not supported (해당 http 버전 지원되지 않음)
Reverse proxy 컴퓨터 네트워크에서 클라이언트를 대신해서 한 대 이상의 서버로부터 자원을 추출하는 프록시 서버의 일종 리버스 프록시 - 위키백과, 우리 모두의 백과사전
path Variable Quary parameter를 어느 상황에 사용할까? Path Variable은 특정 인덱스에 대한 조회. Query String 은 특정 값으로 필터링. Example) 아이디가 20번인 유저 조회 -> Path Variable 사용 -> GET /user/:userid 이름이 james이고 20살인 유저 조회 -> Query String 사용 -> GET /user?userName=james&?age=20 만약 어떤 resource를 식별하고 싶으면 Path Variable을 사용하고...정렬이나 필터링을 한다면 Query Parameter를 사용하는 것이 가장 이상적