코드스테이츠 section2 Unit8(REST API/네트워크 심화)

---

REST 성숙도 모델 - 0단계

• 0단계에서는 단순히 HTTP 프로토콜을 사용하기만 해도 됨 => but, REST API라 할 수 없음(restful 하지 않음?)

---

REST 성숙도 모델 - 1단계

• 개별 리소스(Resource)와의 통신을 준수해야 함 => 웹에서 사용되는 모든 데이터나 자원(Resource)을 HTTP URI로 표현! => 모든 자원은 개별 리소스에 맞는 endpoint을 사용해야 함 => 요청 및 받는 자원에 대한 정보를 응답으로 전달해야 한다는 것이 1단계의 핵심! 
  • endpoint: 컴퓨터 네트워크에 연결 => 컴퓨터 네트워크와 정보를 교환하는 물리적 디바이스 (ex: 모바일, 서버 등등) '
  • https://www.microsoft.com/ko-kr/security/business/security-101/what-is-an-endpoint

엔드포인트란 무엇인가요? | Microsoft 보안

• 0단계 요청에서의 엔드포인트로 모두 (/appointment)-endpoint의 종류 중 하나인듯! => 요청하는 리소스에 따라서, endpoint를 구분하여 사용한다! 

• 위 예시에서 받게 되는 자원(리소스)는 허준이라는 의사의 예약 가능한 시간대임 => 따라서, 요청시 /doctors/이란 endpoint을 사용함! 
• 특정 시간에 예약하게 되면, 실제 slots라는 리소스의 123이라는 id를 가진 리소스가 변경되기 때문에, 하단의 특정 시간에 예약이라는 요청에서는 /slots/123으로 실제 변경되는 리소스를 엔드포인트로 사용함!
• 변경 리소스의 종류/제공되는 응답의 종류에 따라 각각 다른 엔드포인트를 사용하게 됨 (적절한 엔드포인트의 사용이 중요하다!) => 동사X/HTTP/ 리소스에 집중한 명사 형태 단어가 바람직함

• 경우에 따라서, 실패 응답을 받을 수도 있다

---

REST 성숙도 모델 - 2단계

• CRUD(Create, Read, Update, Delete)에 맞게 HTTP 메서드를 사용하는 것에 중점을 둔다 => 앞 단계에서는 CRUD와 상관없이 POST 메서드를 사용하는 중, 이느 CRUD에 따른 적합한 메서드 사용 방법이 아님! 
• 예약 가능한 시간을 확인 => 시간을 조회함을 의미(READ) => 특정 시간 예약은 예약 생성(CREATE)을 의미 => 조회는 GET 메서드를 사용하여 요청하고(GET은 body가 없기 때문에 query parameter를 사용=> 필요한 리소스 전달) => 예악 생성을 위해서는 POST 메서드를 사용 => 반환되는 응답이 중요하다 => 새롭게 생성된 리소스를 응답으로 보내기 때문에 201 created로 명확하게 작성! => 관련 리소스를 클라이언트가 Location Header에 작성된 URI를 통해 확인할 수 있으면 2단계를 충족한 것!

• HTTP 메서드 사용 규칙: 
  • GET: 서버의 데이터를 변환하지 않는 요청시 사용
  • POST: 요청마다 새로운 리소스 생성/ PUT: 요청마다 같은 리소스를 반환(멱등성-idempotent) => 둘을 잘 구분해서 사용하는 것이 중요하다 
  • https://developer.mozilla.org/en-US/docs/Glossary/Idempotent

Idempotent - MDN Web Docs Glossary: Definitions of Web-related terms | MDN

• PUT과 PATCH도 구분해서 사용해야 함! => PUT:은 교체/ PATCH는 수정의 용도임! 
• 2단계까지 적용해도 잘 적용된 REST API라고 한다 => 실제로 3단계까지 적용한 경우는 드물다! 

---

REST 성숙도 모델 - 3단계

• HATEOAS(Hypermedia As The Engine Of Application State)라는 약어로 표현되는 하이퍼미디어 컨트롤을 적용함!
• 3단계의 요청은 2단계와 동일  => 응답에는 리소스의 URI를 포함하여 링크 요소를 삽입하여 작성해야 함!

• 그 시간대에 예약할 수 있는 링크/특정 시간 예약 후 예약을 다시 확인할 수 있는 링크를 작성해 넣을 수도 있다 => 클라이언트 개발자들은 해당 링크를 통해 효율적인 리소스와 기능에 접근할 수 있게 할 수 있음

---

Open API

https://www.data.go.kr/data/15103919/fileData.do#/

우체국금융개발원_연구보고서_20230127

• API마다 정해진 규칙이 있음 => 제한 사항 등이 존재함(가격, 정보의 제한 등)
• 대표적인 open API webpage: 

https://openweathermap.org/api

Weather API - OpenWeatherMap

API Key

• API를 사용하기 위해서는 API key가 필요하다 => 서버의 문을 여는 열쇄 => 로그인한 이용자에게 자원에 접근할 수 있는 권한을 API Key의 형태로 제공을 한다 => 데이터를 요청할 때 API key를 같이 전달해야 원하는 응답을 받을 수 있음! 

---

레퍼런스(REST API 가이드라인): 

https://cloud.google.com/apis/design/resources?hl=ko 

리소스 중심 디자인  |  Cloud API  |  Google Cloud

https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md

GitHub - microsoft/api-guidelines: Microsoft REST API Guidelines