R.E.S.T. +-ful A.P.I

Keun·2022년 6월 16일

좀 알고쓰자

아래에서 위로, 대각선으로 성장중.

목록 보기

8/19

RESTFUL API? REST API?

프로젝트하면서 백엔드에서,

"API 만들었어요 확인하고 문제되는거 말씀해주세요."

그럼 혼자 나는,

"그래요, 잠시만요, GET요청부터 해볼게요"

400 500 등 이상한 에러가뜨면,

나는, "xxxxxx/xxxx 안되고있어요 확인해주세요"

백엔드가그러면, "엇, 그럴리가...엇 안되네요 알겠습니다!"

아니면 내가, "엇 제가 다르게 하고있었어요 죄송합니다!"

처음 혹은 백엔드와 통신할때 이런다항상.

기획 회의할때부터 저 말은 나온다.

"REST API 사용 할거에요~ RESTFUL~"

RESTFUL? -> 편안한 뭔가 편한 이런뜻인데...
RESTFUL API? -> 편한 API? 내가 개발자 공부하면서 인생 편한적 없었는데아직?

REST부터

REST -> REpresentational State Transfer 뭔가 표현적인 상태 이동? 구상적인 표현?
"자원을 이름 (자원의 표현)으로 구분해 해당 자원의 상태(정보)를 주고받은 모든것을 의미."
-> RESOURCE자원의 REPRESENTATION표현에 의한 상태전달이라는 뜻이라는데... 흠...

"REST는 CLIENT 와 SERVER사이의 통신 방식 중 하나입니다."

자원: 말그대로 소프트웨어가 가지는 모든 자원들. 문서, 그림, 데이터, 소프트웨어가 관리하는 모든것들 등등
표현: 그 자원을 잘 표현한것.
예) DB을 열었다. 요리 레시피 정보가 쫘르르르륵 나온다. 이 쫘르르륵 나온 정보에 대해서 단순히 깔끔하게 표현할 때 -> cookingrecipe 를 자원의 표현으로 정할 수 있다.
상태전달: 위에서 cookingreciple라고 하는 자원의 상태로 표현한 것을 요청하고 응답한다. 이때 형식은 나는 JSON을 많이 써봤다. (일반적으로, JSON 과 XML 을 많이 쓴다고함.)

왜 이걸 쓸까 라는 생각이 드는 순간, 감사하게도 내가 찾은 기술 블로그에서 설명해주신다: 기존의 웹기술과 HTTP 프로토콜을 그대로 활용하기 때문에.

여기서 잠깐!

나 이상하게 헷갈린다...URI, URL 등등. 이상하게 좀 어정쩡하게 아는 기분이다. 이참에 제대로 알고 넘어갑시다.

URI는 Uniform Resource Identifier
URL은 Uniform Resource Locator
URN은 Uniform Resource Name
URI = URN + URL

그림이랑 내가 현재 글쓰고 있는 주소창에 있는 URL보고 한번에 이해. 자 다시 REST시작.

REST의 구성요소

내가 프로젝트를 하면서도 느끼지만, REST는 다음과 같은 세가지 구성요소를 갖는다.

(1) 자원(Resource) -> URI = URL + URN
지금 쓰고있는 이 벨로그 글 URI 보여주면~
https://velog.io/write?id=24e52e79-f5f6-44e3-889a-6a6219ac962d
id=24e@!#!@#!@#!@# 이 부분이 지원 구별하는 id. 서버에 존재한다.
이것으로 Client는 서버와 통신할때 자원을 찾는다.
여담이지만, 미국에서 한 챕터의 프레젠테이션을 찾았는데, 그 다음 챕터의 자료도 있을까싶어서 뒤에 id에서 번호라던가 알파벳을 나름 머리써서 올렸더니 다음챕터 나와서 와우 했었다. 그런데 이렇게까지 id가복잡하진 않았지...

(2) 행위(Verb) -> Method
CRUD(CREATE, READ, UPDATE, DELETE) -> GET POST PUT PATCH DELETE 메소드! 이걸로 내가 필요한것을 요청하고 서버에서 저 메소드 대로 응답해준다. 이것들은 HTTP프로토콜의 METHOD라고 하는데 이 부분이 강력하게 왜 RESTFUL API를 사용하는지 말해주는 것 같다.
내 경험 곁들여보면:
POST (CREATE -> 무엇인가를 입력해서, 서버에 무엇인가를 요청을 하면 서버에서 내가 원하는 정보를 응답해준다.)
GET (READ -> 서버에 무엇인가를 입력한다기 보단 요청을 하면, 서버에서 응답을 할때 자세하게 답해주는게 아니라 요청에 대해서 반응만 해주는 느낌이다? 클라이언트에서 요청만 한 느낌.
PUT (UPDATE -> 서버에 있는 내가 입력했던 전체 정보들을 바꿀때)
PATCH (UPDATE -> PUT이랑 비슷한데, 대신에 다 바꾸는게 아니라 딱 어느 일부분만 바꾼다.)
DELETE (DELETE -> 말그대로 서버에 있는 정보를 삭제할때 쓴다. 나도 이것은 써본적이 없다. 그런데 안전성 문제로 서버에서 비활성화 시킨다고 한다. 아하! 그럼 말좀 해주지..몰랐어

(3) 표현(Representation of Resource)

CLIET 와 SERVER가 일반적으로 데이터를 주고받는 형태는 JSON, XML, TEXT, RSS등이 있다.

XML (eXtensible Markup Language)
JSON (JavaScript Object Notation)

와 잠깐 여담인데... 이거 쓰면서 그동안 막 아무것도 모르고 '일단 머리박고 쓰자'에서 점점 뭔가 개념 잡혀간다. 확실히 머리박고 써보고나서 개념정리하는 것도 또하나의 공부법이긴 한가보다. 나는 원래 개념 안익히고 바로 시작하면 어질어질해서 집중도 잘 안되고 진도도 안나가는데...이게 되는구나...신기할뿐이다 아무튼 특징에 대해서 공부해봅시다.

REST의 특징

(1) 지금까지 내가 프로젝트 한 경험으로 말한다면, SERVER-CLIENT(서버-클라이언트 구조) 그냥 나는 프론트 - 백엔드 구조로 느낌으로 알고 넘어가려한다.
자원이 있으면 SERVER, 자원을 요청하면 CLIENT.
CLIENT: 사용자 인증, context(세션, 로그인정보) 직접 관리.
REST SERVER: API제공하고, 비즈니스 로직 처리 및 저장 책임.

오 신기해. 내가 해본 모든 경험이 개념화 되어있다니 ㅋㅋㅋㅋ

(2) Stateless (무상태)

https://www.interviewbit.com/blog/stateful-vs-stateless/#:~:text=Stateful%20expects%20a%20response%20and,the%20state%20of%20the%20request.&text=This%20makes%20the%20design%20heavy,data%20needs%20to%20be%20stored.

이것은 STATEFUL VS. STATELESS 차이이다. 일단 간단하게, stateful은 모든 것을 다 알고싶은 우리엄마, stateless 일단 냅두고 지켜보는 우리아빠 정도로 느낌 가져가자.

HTTP -> STATELESS -> REST도 마찬가지. 왜냐하면 HTTP기반으로 REST 동작하니까.
CLIENT의 context를 Server에 저장하지 않습니다.
* 세션과 쿠키 신경 안써도 되서 구현이 단순하다고한다....
각 Server의 "각각각각각"들의 요청을 완전히 별개의 것으로 인식하고 처리한다.
* 각 API서버는 Clinet의 요청만을 단순 처리한다.-> 각각 처리한다고 했으니까 그만큼 요청들을 단순 처리한다는 말인 것 같다.
- 즉, 이전요청이 다음 요청의처리에 연관되면 안된다 -> 모든지 각각 개인주의 차가운 느낌으로 처리해야하는데 연관되면 안된다는 느낌인 것 같은데...(DB에 의해 바뀌는 것은 허용)
- Server의 처리 방식에 일관성을 부여하기 때문에 서비스의 자유도가 높아집니다! -> 차가운 아이인건 맞지만 그래도 심성은 따뜻하다. 왜냐하면 서비스 자유도 주니까. 능력주의인듯.
  
  난 저렇게 내 느낌대로 써야 뭔가 공부가 잘되더라. 아무튼. 쉿 하고.

(3) Cacheable (캐시 처리 기능)

캐시에 대해...참고사항

https://mangkyu.tistory.com/69

와 OSI 계층, TCP 인터넷 계층 말고 저장공간 계층구조....이거 학부때 배웠던것인데 와 생각났다진짜신기하다. 사람의 뇌라는게 참. 갑자기 확 스파크...이게 생각이나네..

우선 조용히하고 쉿하고. 쉿.

캐시는 이런 느낌으로 알면 된다. 내가 이 벨로그 작성하고 닫았어. 그런데? 엇? 나 지금 글 수정 해야할것같아 하고서 브라우저 다시 킨다. 킨다음에 우리는 url에다가 주소를 입력할 것이다.
https://velog.io...a#@$!#!@#!@그런데. 때마침 우리가 잘 알다시피 주소창에 자동으로 저렇게 치다보면 전에 방문했던 기록들을 참고해서 자동완성으로 주소를 입력해준다. 그런데 여기서 자동완성 검색기능이 캐시가 아니라 자동검색되게 방문기록을 찾아보았을때 확인해 주는 것을 가능하게 해주는게 캐시다. 캐시는 한마디로 데이터를 미리 메모리에 데이터 저장해 놓았다가 우리가 다시 필요로 할때, 불러다 써주는 느낌!

그래서,

캐싱기능 적용 가능
대량의 요청을 효율적으로 처리 가능

(4) Layered System (계층구조) -> 이거 살짝 네트워크적 요소가 강해서...잘 모르긴하는데 열심히 찾아봤음..

우선 프록시와 게이트웨이를 알아야 할 것 같아서...뒤적거려본결과...

https://swimjiy.github.io/2020-04-11-web-gateway

감사합니다...블로거님...

Client 는 RESTAPI SERVER 만 호출가능. -> 당연하지
REST SERVER는 다중계층으로 구성가능. -> 사실 이말 무슨말인지 100% 이해는 아니다..찾아봅시다....나중에...
* 보안, 로드밸런싱, 암호화 등 (-> 대충 보안 강화한다 이런뜻같다) 을 위한 계층을 추가하여 구조를 변경 할 수 있습니다.
- Proxy, Gateway와 같은 네트워크 기반의 중간매체를 사용할 수 있습니다.
- 단, Client 쪽에서 중간매체서버인지 어디랑 통신하는지 몰라요~

(5) Uniform Interface (인터페이스 일관성)

URI로 지정한 Resource 에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍쳐 스타일을 의미합니다. -> crud 이런게 한결같이 폼의 형태로 그 형태 그대로 요청하고 응답한다는 그런 말 같아요!
HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하며, Loosely Coupling (느슨한 결함) 형태를 갖습니다.
* 즉, 특정 언어나 기술에 종속되지 않음.

(6) Self-Descriptive (자체표현) -> 요청 메세지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.

REST API에 대해 이제 시작. 그동안은 REST 개념탑재.

와 이제 드디어 REST API에 대해 알아간다.

그런데 이미 내가 프로젝트때 많이 써본것이여서, 전반적으로 내가봤을때 REST 개념에 API합친듯하 느낌.

REST API란-> REST특징을 기반으로 서비스 API를 구현한것. 많은 Open Api (카카오맵, 구글맵, 공공데이터 등등) 마이크로서비스(하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 기업 대부분이 REST API 제공한다고 한다. JSON 형식의 데이터로 API 보여주던데...그렇구나....

REST API특징-> 이건 내가 처음에 맨 처음으로 axios사용해서 백엔드랑 통신할때도 느낀거지만, 그냥 아무것도 개념도 없는 상태로 봐도, 대충 영어로 메소드 읽고 데이터 정보 무엇이 담겨있나정도 확인하다보면 대충 추론 가능하다. 이것이 큰 특징이라고한다.

REST API 디자인 가이드

갑자기 무슨 디자인이냐? 그런데. 이게 꾀나 중요하다. 나는 만들어 본 적은 없지만, 백엔드에서 하는 것을 흠칫 옆에서 들어보고 봤는데, 솔직히 내 눈에서 보면 그냥 URI이름짜고 그러고 있는건데 별거 아닌것 같이 보이지만, 이것이 API설계시 가장 중요하다고 한다.
-> 2가지로 요약 가능하다고 한다.

첫번째, URI는 정보의 자원을 표현해야한다. ->
두번째, 자원에 대한 HTTP Method (GET, POST, PUT, PATCH, DELETE)로 표현한다.
* 행위(Method)는 URI에 포함하지 않는다.

REST API 설계 규칙.
1. URI는 명사를 사용한다.(리소스명은 동사가 아닌 명사를 사용해야 한다.)
1-1. 아래와 같은 동사를 사용하지 말 것

/getAllUsers
/getUserById
/createNewUser
/updateUser
/deleteUser

슬래시( / )로 계층 관계를 표현한다.
URI 마지막 문자로 슬래시 ( / )를 포함하지 않는다.
밑줄( _ )을 사용하지 않고, 하이픈( - )을 사용한다. -> 이건 기억난다. 저번에 백엔드 어떤분이 오셔서 이거 밑줄 사용하지 말아야한다고 지적하고 갔었다...
URI는 소문자로만 구성한다. -> 이거는 지켜지지 못했던것같다. 프로젝트 한것 기억해보면...아직 있는듯...
HTTP 응답 상태 코드 사용

클라이언트는 해당 요청에 대한 실패, 처리완료 또는 잘못된 요청 등에 대한 피드백을 받아야 한다.
HTTP 상태 코드 정리
-> 굉장한 에러의 바다에 빠지게 해준다. 아주좋다.

파일확장자는 URI에 포함하지 않는다.
Ex) http://dev-coco.tistory.com/restapi/220/photo.jpg (X)

REST API VS. RESTFUL API 차이는?

RESTFUL, 우리의 편안한 RESTFUL API는 위와 같이 REST설계규칙을 잘 준수한 것이다.
즉, REST의 원리를 잘 따르는 시스템을 RESTFUL이란 용어로 지칭된다고 한다.
잘 준수된 RESTFUL API를 보면 눈에 확 들어온다! 그것에 모든 정보가 다 잘 담겨있다.

요약하자면-> URI로 무슨 정보 무슨자원 표현이 가능하고, 자원이 어떻게 이동하고 이런 메소드들을 HTTP METHOD에 명시한다는 것!!

참고, 굉장히 많이 참고, 잘배웠습니다: