->예전에 REST API에 대해 공부를 하려고 노력했던 흔적
참고강의 - Day1, 2-2. 그런 REST API로 괜찮은가
REST API
-> REST API란 REST 아키텍쳐 스타일을 따르는 API
그럼 REST는 뭐냐?
->분산 하이퍼 미디어 시스템 (예를 들면 웹같은 것들)을 위한 아키텍쳐 스타일
아키텍쳐 스타일은 뭔데?
-> 제약 조건들의 집합
그러니깐 결론적으로
📌REST API
이 제약 조건들을 모두지켜야 REST를 따른다라고 말할 수 있다.
그럼 뭘 지켜야하나..???
사실 REST는 아키텍쳐 스타일이라고 말을하면서 하이브리드 아키텍처 스타일이라고도 말한다.
왜냐하면 , 아키텍쳐 스타일 이면서 동시에 아키텍쳐 스타일의 집합이기 떄문이다.
REST를 구성하는 스타일
전부 아키텍처 스타일이다.
1️⃣ Client-Server
2️⃣ Stateless
3️⃣ Cache
4️⃣ ❗Uniform Interface❗
5️⃣ Hierarchical system (계층구조) / Layered System
6️⃣ Code on demand(Optional)
모두 아키텍쳐 스타일이기 때문에 REST가 아키텍쳐 스타일 이면서 동시에 아키텍쳐 스타일의 집합이라고 불린다.
(그리고 4번에 저렇게 칠해놓은 이유가 있다.)
대체로 오늘날에 REST API로 굴리는 것들은 잘 지키고 있다.
어떻게 잘 지키고있냐?
HTTP만 잘 사용해도 1️⃣~5️⃣는 그냥 준수한다고 한다.
6️⃣ Code on demand 같은 경우는 서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다! 라는 뜻을 가지기 때문에
옵션이다.. 해도되고...안해도 되고... ( 바로 생각나는 예시 : 자바 스크립트!!✅ )
그래서 별로 어렵지 않은 요소들이 있는데, 단 하나.
만족하기가 가장 까다로운 아키텍쳐 스타일이 있다.
맞다. `4️⃣ ❗Uniform Interface❗`얘다.
4️⃣ Uniform Interface 의 제약조건
Uniform Interface도 하나의 아키텍처 스타일이기 때문에 안에 어떤 제약조건들이 있는지 확인할 수 있다.
- identification of resources
- manipulation of resources through representations
- self-descriptive messages
- hypermedia as the engine of application state (HATEOAS)
볼드체가 있/없 유무로 보아 또 차이가 있겠지???
identification of resources 와 manipulation of resources through representations는 잘 지켜지고 있기 때문이다.
남은 두가지는 오늘날에 활용되고 있는 REST API가 거의 활용하지 못하고 있다.
✅ identification of resources
리소스들이 URI로 식별이 되어야 한다는 제약 조건
✅ manipulation of resources through representations
representation 전송을 통해서 리소스를 조작해야 한다는 제약 조건
리소스 만들기, 업데이트, 삭제하기 할때 HTTP 메세지에다가 그 표현을 담아서 전송하면 된다는 뜻이라고 한다.
이미 잘 지켜지고 있음!!
🟩❗self-descriptive messages
메시지는 스스로를 설명해야 한다는 제약조건
예를 들어 이런 메시지가 있다고 치자.
딱 봤을때는 음 GET 메서드로 보내는 요청 까지만 알 수 있다.
무엇인가 빠졌기 때문이다.
목적지가 빠져있다.
목적지를 주면 이제서야 self-descriptive하다고 생각 될 수 있다.
따라서 제일 윗 사진인 경우는 self-descriptive messages제약 조건을 만족하지 못하고 있다.
REQUEST를 줬으니 RESPONSE예제도 있다.
이것 같은 경우에도 정상적인 통신성공 메시지다.
근데 이 메시지를 받은 클라이언트는 정보가 빠져있어서 읽지 못한다.
어떤 방식으로 정보가 쓰였는지 기재를 안해줬기 때문이다.
이렇게 하면 완성이 된것일까?
맞다
이거 어떻게 설명할건데
이런식으로 제이슨의 내용을 어떻게 읽어야할건지 명시해줘야함
🟩❗hypermedia as the engine of application state (HATEOAS)
헤이티오스라고 읽넹
애플리케이션의 상태가 항상 Hyperlink를 이용해 전이되어야 한다는 제약조건
즉, 페이지가 이동될 때 마다 홈페이지 안에있는 링크로 다음 페이지를 넘어갈 수 있는가? 를 만족해야함
HTML같은 경우는 <a> 태그를 통해서 만족할 수 있다.
JSON 같은경우도 Link 헤더에서 다른리소스와 하이퍼링크로 연결되어있는 다른 리소스를 적용할 수 있는 기능이 있다.
참고사진을 보면 이전 페이지와 다음 페이지가 어디인지 텍스트만 봤지만 알수있다.
내용을 읽는 사람이 아 저기 저렇게 써져있으니 다음으로 넘어갈 페이지는 이쪽이군! 하면서 이해가 가능한 상태여야한다는 소리임
❓왜 Uniform Interface를 만족해야 하는가
바로 독립적 진화를 이유로 들 수 있다.
이 독립적 진화는 무엇인가??
서버와 클라이언트가 각각 독립적으로 진화한다.
예를들어서 서버가 여러 API와 URI가 교체되었지만,
클라이언트에서 업데이트 할 필요가 없어도 된다는 뜻이다.
이 요건이 REST의 목적에 직결되기 때문에 독립적 진화는 반드시 이뤄져야 한다.
이처럼 REST는 웹의 독립적 진화를 위해 만들어졌다.
웹은 이 REST에 영향을 받아서 독립적 진화가 이뤄지고 있다
-> REST는 성공적이다.
❗self-descriptive messages 와 ❗HATEOAS 가 독립적 진화에 어떻게 도움이 되나???
self-descriptive messages : 서버- 클라이언트 중 아무거나가 어떻게 변하던지 서로 교환하는 메시지는 항상 자기자신에 대한 설명이 충분히 이뤄지고있음.
-> 언제나 메시지만 가지고 해석이 가능하다HATEOAS : 애플리케이션 상태 전이의 late binding
웹이 흐름을 따라서 이동하는데 앞, 뒤 의 페이지가 하이퍼링크로 이뤄져 있으면 그 링크만 바꾸면 언제든지 이동이 자유롭기 때문임
동적으로 바뀌는 링크는 서버-클라이언트와 독립적임
그런데 REST API는?
REST API는 REST 아키텍쳐 스타일을 따라야 한다.
그런데 아까 말햇다 싶이 요즘 나오는 REST API 들은 대부분 이 REST 아키텍쳐 스타일을 따르지 않는다.
REST API도 저 제약 조건을 무조건 지켜야 함!!!!!!!!!!!!!!!!!
📌 다시보는 REST API 뜻
REST API는 하이퍼 텍스트를 포함한 ❗self-descriptive한 메시지의 4️⃣ Uniform Interface를 통해 리소스에 접근하는 API
꼭 REST를 따라야 할까??
그럴 필요는 없다. 클라이언트-서버를 모두 통제할 수 있거나, 진화에 관심이 없다면(여러차례의 업데이트를 클라이언트나 서버가 감당할 수 있다면) 지키지 않아도 된다.
REST를 따르기 위해서 시간과 비용이 들기 때문에 어떤 쪽이 더 효율적인지 판단행얗 ㅏㅁ
✔️ HTTP API VS REST API
가장 큰 차이점으로 결국 Media Type이 될 수 있다.
비교를 JSON과 했는데, JSON은 이 데이터들을 Uniform Interface에 만족하기 위해 data에 다양한 방법으로 하이퍼 링크를 표현하거나, HTTP 헤더로 Link나 Location을 표현한다.
솔직히 여기서 REST를 다 갖춘 API를 REST API라고 부르는데 그럼 RESTful API 는 뭘더 갖춘건가?? 했는데 그 반대다. 적당히 타협본 REST API 따라한거...
REST API vs RESTful API
사실상 REST의 원칙을 모두 따르는 것이 어렵긴하다.
프로젝트마다 모든 REST를 따라야할 때가 있고, 적당히 타협하면서 지킬 수 있는 것만 골라서 할 떄도 있다.
사용자에게 직접적인 서비스를 제공하는 프로젝트일수록 REST 를 엄격하게 지켜야 할 것이고,
뭐.. 회사 내부적인 시스템으로서 서버-클라이언트간의 독립이 불필요한 경우는 위에서 말했다 싶이 조율할 수 있을 것이다.
그렇게 팀과 프로젝트 단위에서 어떻게 REST하게 아키텍쳐 스타일을 정할 것인지 결정하고,
각각이 만들어 내는 API를 RESTful API라고 할 수 있다.
📌 즉, REST하게 자원 관리를 하되, 상황에 맞게 유연한 설계가 필요하다.
사실 이 두개 키워드를 여기저기 검색도하고 지피티 코파일럿 다돌려봤는데 말하는게 다 달라서 너무 고민이 많았다...
그래서 튜터님께 여쭤봤는데,
개발자 마다 RESTful API에 대해서 말하는 것을 다를 수 밖에 없고, 어떤 서비스를 제공할 것인지에 따라서
거기서 사용하는 RESTful API가 바뀔 수 있다고 함..!!! 틀릴시 슬플듯
마지막으로 RESTful API 사례 몇개 적어놔야겠다
RESTful API라고 막 API 이름이 RESTful API 인게아님...
✅ 대표적인 RESTful API 사례
🔹 웹 서비스 API
- GitHub API → GET /users/{username}/repos (사용자 리포지토리 조회)
- Google Maps API → GET /maps/api/geocode/json (주소 -> 좌표 변환)
🔹 클라우드 서비스 API
- AWS S3 API → PUT /{bucket}/{object} (파일 업로드)
- Google Drive API → DELETE /drive/v3/files/{fileId} (파일 삭제)
🔹 소셜 로그인 API (OAuth 2.0 기반)- Google OAuth API → GET /oauth2/v4/token
🔹 기타 서비스 API- Firebase Firestore API → POST /v1/projects/{projectId}/databases/(default)/documents/{collectionId}
☑️ RESTful API가 적용되는 곳
✔ 모바일 앱 (iOS, Android) 백엔드
✔ 프론트엔드(React, Vue, Angular)와의 통신
✔ 마이크로서비스 간 통신
🔍 API 가 얼마나 REST한지 결정하는 기준 = Maturity Model (성숙도 모델)
RESTful API의 성숙도를 4단계(Level 0~3)로 나눠서 평가할 수 있다.
Level 0 - The Swamp of POX
Level 1 - Resources
Level 2 - HTTP Verbs
Level 3 - Hypermedia Controls
Level. 0 : The Swamp of POX
- 웹 서비스를 제공하기 위해 URL만 매핑해 놓은 상태
- HTTP를 단순한 트랜스포트(운반) 수단으로만 사용
- HTTP 메서드(GET, POST, PUT 등) 구분 없이 모든 요청을 POST로 처리
Level. 1 : Resources
- 외부로 공개하려는 리소스에 대해서 의미있는 URL로 표현하기 시작한 단계
- 적절한 패턴을 가지고 작성 되었지만 HTTP의 메소드 별로 서비스를 구분하여 사용하고 있지는 않다.
- 즉, 서비스 형태나 작업의 종류에 맞추어 적절한 HTTP 메소드를 지정하고 있지 않다.
Level. 2 : HTTP Verbs(HTTP 메서드 활용)
- 우리가 제공하고자 하는 리소스를 적절하게 용도와 상태에 따라서 HTTP Methods에 맞게 설계하고 서비스하는 단계.
- 만약 리소스의 상태가 읽기 용도로 사용되는 데이터라고 한다면 GET Method를 사용한다.
- 새로운 리소스를 추가하는 경우는 POST Method
- 기존 리소스의 상태를 변경하기 위해서는 PUT, PATCH Method
- 리소스를 삭제하고자 할 때에는 Delete Method를 사용하여 서비스의 상태를 표현한다.
- RESTful Service의 DB에 저장된 리소스를 확인하고 이러한 데이터를 조작하기 위해서 RUD와 매칭되는 HTTP Methods를 이용하여 서비스 하는 것을 Level2 단계라고 한다.
- HTTP의 메소드를 이용하여 리소스의 상태를 구분하여 서비스 하게 되면 비슷한 이름의 URI라 하더라도 HTTP Method에 따라서 다른 형태의 서비스를 제공할 수 있게 된다.
Level. 3 : Hypermedia Controls (HATEOAS)
- 데이터를 가지고 그 다음 작업에서 어떠한 작업을 할 수 있는지 상태 정보를 함께 넘겨준다.
- 클라이언트 측에서는 서버가 제공하는 서비스를 일일이 찾는 수고를 겪지 않아도 된다.
- 엔드포인트만 가지고 있으면 서버가 제공할 수 있는 다음, 그 다음 URI값을 알 수 있다.
- 응답에 다음 액션을 위한 링크(link) 제공
- 클라이언트가 API 문서를 참고하지 않고도 동적으로 API를 탐색할 수 있음
{
"id": 123,
"name": "Alice",
"links": [
{ "rel": "self", "href": "/users/123" },
{ "rel": "friends", "href": "/users/123/friends" },
{ "rel": "posts", "href": "/users/123/posts" }
]
}
하이퍼 링크 의미가있지요?
🗝️ 정리
🔓 RESTful API 정리
REST하게 자원 관리를 하되, 상황에 맞게 유연한 API설계를 해야함!
교과서(REST API)는 있지만 따라가기 어려우니 프로젝트의 상황과 팀원간의 협의를 통해 교과서를 따라가기 위한 노력을 하자
자원은 서버, 클라이언트의 버전과 독립적일수록 좋다!
마찬가지로 서버와 클라이언트도 서로서로 업데이트 상황이나 환경 따라서 영향을 받지 않도록 하는것이 이상적이다.
🔓 Maturity Model
무조건 2단계 이상 권장!!!
