[UMC] Server 6주차 Restful API와 프레임워크

😺 강의 내용 정리 

1. HTTP 통신

클라이언트가 서버에게 웹페이지를 보여달라하는 것 = 요청

서버가 클라이언트에게 요청 받은 것에 대한 대답으로 웹브라우저를 띄어주는 것 = 응답

 

데이터가 패킷 형태로 왔다갔다함

Packet = Header + Body = 송수신주소 + 전송할 데이터

 

데이터를 주고 받는 방식 : get, post, put, patch, delete >> http 메소드

(1) GET 메소드

무언가를 조회할 때 사용됨

클라이언트는 서버에게 어떤 정보를 조회할 것인지 알려줘야함

querystring을 이용해 전달하는 방식

(2) POST 메소드

무언가를 생성할 때 사용됨 (ex.회원가입)

(3) PUT, PATCH : 수정할 때

(4) DELETE : 삭제 할때

 

2. API : Application Programming Interface

API 통신을 할 때에는 서버와 클라이언트간 포맷이 통일되어있어야한다. 이러한 문서를 API 명세서라고 한다. 

인스타그램 api 명세서를 작성해보았다.

3. Restful API

1) 메소드 : 동사 / uri : 명사

(회원가입에서는 post/users -> 유저를 생성)

(100번 유저의 정보를 조회 할 때에는 path variable을 이용해 get/users/100)

(uri를 명시할 때, 클라이언트에 전달을 할 때에는 get/users/userIdx)

 

* query string : 검색이나 필터링, 페이징에서 사용

(필터링 -> get/users?gender=female)

 

2) 명사와 명사의 구분자는 하이픈으로 

blocked-users

 

3) get과 delete에는 body 쓰지 않기

 

4) HTTP 메소드는 실제 DB에서 동작하는 기준으로 

회원 삭제의 경우 delete가 아닌 patch 메소드 사용

 

4. 프레임워크

서버 템플릿 구조

클라 -> 서버 요청

(1) route

: 요청을 라우팅 처리, 해당 uri와 매핑된 contoller로 

(2) contoller

: provider/service에 요청을 전달할 때 path variable, querystring, body에 있는 데이터를 가져옴 ->  provider/service의 파라미터 값으로 전달해줌! 

: 형식적 validation (이메일이 빈 값인지, 이메일이 너무 길지는 않은지)

(3) provider/service

provider : 조회의 작업

service : 조회 외 모든 작업

: 비즈니스 로직이 이루어짐

: transaction 처리 

: 의미적 validation (중복 처리)

(4) dao

: 실질적인 쿼리 작성 + 처리

---

🐯 핵심 키워드 

0. HTTP 

: www 상에서 문서를 주고 받는 프로토콜

: TCP,UDP를 사용하며 포트번호는 80이다. 

 

1. HTTP 패킷

: 클라이언트가 서버로 요청할 때 보내는 데이터

: 헤더 + 바디

- 헤더 : 사용한 HTTP 메서드, 클라이언트 정보, 브라우저 정보, 접속할 URL 등 과 같은 클라이언트 정보를 담고 있다.

- 바디 : 클라이언트가 요청한 실제 데이터

• 요청헤더 (Request Header) : 요청하는 페이지의 주소와 현재 컴퓨터의 정보가 전송되는 부분
• 요청바디 (Request Body) : POST 요청시 전송되는 데이터가 들어가는 부분. GET 요청 일때 빈칸
• 응답헤더 (Response Header) : 응답 페이지의 상태와 서버에 관한 정보가 전송되는 부분
• 응답바디 (Response Body) : 페이지의 HTML 소스가 전송되는 부분

2. HTTP 메소드

GET(가져오다)	서버로부터 데이터를 읽거나 검색할 때 사용
POST(게시하다)	Body에 정보를 담아 서버에 데이터를 추가, 작성
PUT(집어넣다)	서버의 데이터를 갱신, 작성
PATCH(고치다)	데이터를 일부분을 수정
DELETE(지우다)	서버의 데이터를 삭제

> 해당 자원 전체를 수정하는 PUT과는 다르게 PATCH는 해당 자원의 일부 부분을 수정한다

 

3. API

: 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스

: 설명을 해보자면 프로그램과 또 다른 프로그램을 연결해주는 다리라고 할 수 있다.

예를 들어 일깅 예보를 알려주는 웹페이지를 만든다고 하면 날씨 정보를 어디선가 받아와야한다. 이때 만약 기상청의 날씨정보를 가져온다고 해보자 그러면  “운영체제나 프로그래밍 언어가 제공하는 기능”이 기상청의 날씨정보가 되는것이고, “응용 프로그램”이 그걸 이용해 만든 일기예보 웹사이트가 되는 것이다!

 

4. 데이터 포맷

http://opendatahandbook.org/guide/ko/appendices/file-formats/

파일 형식

5. Restful API 설계 규칙

1. 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용
2. URI 마지막 문자로 슬래시(/) 포함하지 않음
3. 하이픈(-)은 URI 가독성을 높이는데 사용
4. 밑줄(_)은 URI에 사용하지 않음
5. URI 경로에는 소문자가 적합
6. 파일 확장자는 URI에 포함시키지 않음

https://evan-moon.github.io/2020/04/07/about-restful-api/

프론트엔드와 백엔드가 소통하는 엔드포인트, RESTful API

https://velog.io/@pjh612/REST-API-URI-%EA%B7%9C%EC%B9%99

REST API URI 규칙

6. API Sheet

: API 문서는 누가 봐도 이해할 수 있도록 명확하고 직관적이여야 한다. 

: 클라이언트에게 API 명세서를 제공해야한다. 

: 문서 작성방법에는 swagger, postman, 스프레드시트, gihub siki가 있다

 

7. 프레임워크 vs 라이브러리

라이브러리와 프레임워크의 차이는 제어 흐름에 대한 주도성이 누구에게/어디에 있는가에 있다.

즉, 어플리케이션의 Flow(흐름)를 누가 쥐고 있느냐에 달려 있다.

프레임워크는 전체적인 흐름을 스스로가 쥐고 있으며 사용자는 그 안에서 필요한 코드를 짜 넣으며 반면에 라이브러리는 사용자가 전체적인 흐름을 만들며 라이브러리를 가져다 쓰는 것.

라이브러리는 라이브러리를 가져다가 사용하고 호출하는 측에 전적으로 주도성이 있으며 프레임워크는 그 틀안에 이미 제어 흐름에 대한 주도성이 내재(내포)하고 있다.

프레임워크는 가져다가 사용한다기보다는 거기에 들어가서 사용한다는 느낌/관점으로 접근할 수 있다!!