대외활동/UMC SERVER

6주차 공부 - API와 FrameWork

Debin 2022. 4. 28.

이번 주차에는 코딩 실습이 없고 API작성과 FrameWork에 대한 기초적인 내용을 학습했습니다.

시험기간으로 한 주 휴식!!! 그러나 아직 저는 시험이 끝나지 않았습니다... 그래서 주말 이전에 빠르게 모두 정리하기로!!!!!

본격적으로 시작하겠습니다.

API란 무엇인가?

본인은 노마드코더 React 챌린지를 진행하면서 TMDB API를 사용한적이 있다. 또한 기상청의 API를 사용해 본 적도 있습니다.

그래서 API가 무엇인지, 개념은 가지고 있으나 막상 말과 글로 풀어 설명하려고 하니 꽤 쉽지 않습니다. 일단 정리해보겠습니다.

API란 Application Programming Interface의 약어다.
위키백과의 정의는 다음과 같다.
'API는 컴퓨터나 컴퓨터 프로그램 사이의 연결이다. 일종의 소프트웨어 인터페이스며 다른 종류의 소프트웨어 서비스를 제공한다.'
사용자 인터페이스(UI)는 프로그램과 사용자가 상호작용 하기 위한 인터페이스다.
그렇다면 API도 마찬가지다. API는 프로그램끼리 상호작용하기 위한 인터페이스다. 즉 사용 가이드라고 생각할 수 있다.
API의 API Sheet에 맞춰 보내주면 우리가 원하는 응답 데이터가 사용하려는 프로그램의 api를 통해 리턴된다.
즉 본인이 이해하기로는, 사용자가 API를 이용해 서버 프로그램과 상호작용을 하면서 원하는 데이터를 받을 수 있다.

여기서 API Sheet란?

API를 사용하는 클라이언트를 위한 API 사용법을 알려주는 것을 API Sheet라고 한다.
API Sheet에는 http method, uri, 기능 설명, 서버 반영 여부, 요청 파라미터, API 리턴 값 등 다양한 정보를 알려준다.

그렇다면 API 관련해서 꼭 나오는 단어가 있다. 바로 REST다. REST API란 무엇일까?? 간단하게 알아보자.

REST API란?

Representational State Transfer API의 약어다.
REST API는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다.
이 용어는 2000년 로이 필딩의 박사 학위 논문에서 소개되었다.

REST API의 구성

자원(Resource) - URI
행위(Verb) - HTTP Method
표현(Representations) - JSON, HTML

REST 아키텍처에 적용되는 6가지 제한 조건

인터페이스 일관성 : 일관적인 인터페이스로 분리되어야 한다.
무상태(Stateless) : 각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안 된다,.
캐시 처리 기능(Cacheable) : WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다. 잘 관리되는 캐싱은 클라이언트-서버 간 상호작용을 부분적으로 또는 완전하게 제거하여 scalability와 성능을 향상시킨다.
계층화 (Layered System) : 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다. 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상시키는 데 유용하다.
Code on demand (optional) : 자바 애플릿이나 자바 스키립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.
클라이언트/서버 구조 : 아키텍처를 단순화시키고 작은 단위로 분리함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해준다.

REST 인터페이스의 원칙에 대한 가이드

자원의 식별 : 요청 내에 기술된 개별 자원을 식별할 수 있어야 한다. 웹 기반의 REST 시스템에서의 URI의 사용을 예로 들 수 있다. 자원 그 자체는 클라이언트가 받는 문서와는 개념적으로 분리되어 있다. 예를 들어, 서버는 데이터베이스 내부의 자료를 직접 전송하는 대신, 데이터베이스 레코드를 HTML, XML이나 JSON 등의 형식으로 전송한다.
메시지를 통한 리소스의 조작 : 클라이언트가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면 이것으로 서버 상의 해당 자원을 변경·삭제할 수 있는 충분한 정보를 가지고 있는 것이다.
자기 서술적 메시지 : 각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다. 예를 들어 MIME type과 같은 인터넷 미디어 타입을 전달한다면, 그 메시지에는 어떤 파서를 이용해야 하는지에 대한 정보도 포함해야 한다. 미디어 타입만 가지고도, 클라이언트는 어떻게 그 내용을 처리해야할 지 알 수 있어야 한다. 메시지를 이해하기 위해 그 내용까지 살펴봐야 한다면, 그 메시지는 자기서술적이 아니다. 예를 들어, 단순히 "application/xml"이라는 미디어 타입은, 실제 내용을 다운로드 받지 않으면 그 메시지만 가지고는 무엇을 해야할지에 대해 충분히 알려주지 못한다.
애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어 : 만약에 클라이언트가 관련된 리소스에 접근하기를 원한다면, 리턴되는 지시자에서 구별될 수 있어야 한다. 충분한 콘텍스트 속에서의 URI를 제공해주는 하이퍼텍스트 링크의 예를 들 수 있겠다.

REST API 디자인 가이드

REST API 설계 시 가장 중요한 항목은 2가지다.

URI는 정보의 자원을 표현
자원에 대한 행위는 HTTP METHOD로 표현

먼저 URI가 정보의 자원을 표현한다는 내용에 대해 알아보자. 리소스명은 동사보다 명사를 사용해야 한다!!!!

GET /members/delete/1

위와 같은 방식은 동사를 사용하고 자원을 표현하는데 중점을 두지 않았으므로 Restful하지 않다.

행위는 HTTP method로 나타내야 하고 URI는 리소스를 중점으로 두어야 한다. 수정한 Restful한 API는 아래와 같다.

DELETE /members/1

몇 가지 예시를 더 살펴보자.

GET /members/show/1 X
GET /members/1 O

GET /members/create/2 X
POST /members/2 O

이제 URI 설계 시 주의할 점이다.

슬래시 구분자는 (/) 계층 관계를 나타내는데 사용한다.
URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
하이픈 (-)은 URI 가독성을 높이는데 사용
밑줄(_)은 URI에 사용하지 않는다.
URI에서는 소문자를 사용한다.
파일 확장자는 URI에 포함시키지 않는다. (HTTP HEADER를 사용한다)

이상으로 API에 대한 내용은 마치고 프레임워크에 대해 알아보자.

프레임워크

본인이 정리한 프레임워크의 정의는 아래와 같다. 내친김에 라이브러리와의 차이점도 확인할 수 있게 정리해보았다.

프레임워크 : 어떤 외부 모듈을 사용하는데 이 프로그램에 의해 개발자의 코드가 통제되면 프레임워크다.
라이브러리 : 어떤 외부 모듈을 사용하는데 이 프로그램을 개발자가 통제할 수 있다면 라이브러리다.

프레임워크 템플릿 분석해보기

강의를 통해 프레임워크의 템플릿에 대해 학습했다. 기초적인 개념이 이거다 라는 정도만 알아가자.

이번 강의에서는 DI에 대해서 나오지는 않았다. 스프링은 자바 진영의 DI 프레임워크다.

Route ↔ Controller ↔ Provider/Controller ↔ Dao(Repository)

Route : 요청을 라우팅 처리. route에서 요청이 들어온 URI 와 매핑된 컨트롤러를 호출한다.
Controller: Path Variable, Query String, Body 요청 데이터를 가져온다. 형식적인 Validation을 실행한다. 예를 들어 형식 검사는 이메일이 맞는지, 문자열 길이 검사 등이 있다.
Provider, Controller : 트랜잭션, 비즈니스 로직을 수행한다.
- Provider : 조회 중심적 비즈니스 로직을 수행한다.
- Controller : 그 외의 비즈니스 로직을 수행한다.
- 의미적 Validation을 수행한다. 예를 들어 중복 이메일로 회원가입을 했는지, 해당 유저에게 요청 권한이 있는지 등.
Dao(Repository) : 쿼리를 작성해 DBMS를 통해 DB에 쿼리를 날려 데이터를 가져온다.

본인이 작성한 API 명세서는 다음과 같다. 물리적인 삭제가 아니라 논리적인 삭제를 하도록 DB를 설계하였으므로 DELETE 메소드 보다는 PATCH메소드를 사용했다.

1. 유저 기능

2. 게시글 기능

3. 댓글 기능

4. 팔로잉 기능

마지막 팔로잉 기능을 POST로 두는 것이 맞는지 고민이다. 스터디 때 한번 얘기해보자.

이번에 6주차 강의 말고 게시판 API를 작성할 일이 있었다.

여기서 뭔가 많은 고민이 있었고 특히 게시판 알람 구현에 대해서 고민이 있었다.

그래서 API 관련된 좋은 자료를 찾다가 일상 속 사물이 알려주는 웹 API 디자인이라는 책을 추천 받았다.

이제 저번에 산 SQL 첫걸음 책을 다 읽어가니까 마무리 하면 이 책을 읽어 볼 예정이다.

부족한게 너무 많다고 느껴진다. API 디자인, SQL, git 을 좀 더 잘 활용하기, Serber, aws 등..

본인은 자신이 모르는 것을 아는 것이 중요하다고 생각한다. 더욱더 열심히 해보자!!! 일단 시험부터 마치고.. ㅠㅠ

그리고 모든 개발자들이 REST API에 관해서 강력 추천하는 영상이 있다.

한번씩 꼭 보시면 좋을 것 같다. 우리 스터디원들에게 무조건 추천할 예정 ㅎㅎ 이 발표도 나중에 정리해봐야겠다. 꼭..!

https://deview.kr/2017/schedule/212

그런 REST API로 괜찮은가

발표자 : 이응준

deview.kr

이상으로 포스팅을 마칩니다. 감사합니다!!

참고 자료

https://meetup.toast.com/posts/92

https://ko.wikipedia.org/wiki/REST