REST API / RESTful API 간단 요약 정리

[목차]

1. API란?
2. REST란?2-2. REST 목적2-4. REST API 디자인 가이드
3. 2-5. REST 특징
4. 2-3. REST 구성요소
5. 2-1. REST 란
6. 결론

제가 오늘 설명드릴 내용은 전반적이고 일반적인 내용의 REST API입니다. 학술적으로 정확한 의미의 REST API를 알고싶으신 분은 추가해놓은 유튜브 링크를 통해 해당 영상을 참고부탁드립니다.

[그런 REST API로 괜찮은가]

Day1, 2-2. 그런 REST API로 괜찮은가

 

 

---

1. What is REST?

<OracleGuide  Docs>

 🗣 REST is a way of providing interoperability between computer system on the internet.                   👉🏻  컴퓨터 시스템간 상호 운영성을 제공하는 방법이다. [....🤮 🤢]  뭔말이지...ㅎ..

 

 

 

REST API를 이해하기 전에 먼저 API에 대해 이해할 필요가 있습니다.

API?

⇒ Application Programming Interface

 

사진과 같이 어떤 기계를 만들면 사용자가 그 기능들을 전부 활용할 수 있도록 제어장치를 마련해야 합니다.

컴퓨터의 마우스와 키보드 같은 것들을 인터페이스라고 합니다.

이는 기계와 인간 사이의 소통창구 같은 역할을 합니다.

웹이나 앱을 생각해 보면 사용자가 정보를 제어할 수 있도록 버튼/ 스크롤바/ 슬라이더/ 브라우저 창등

소프트웨어적인 장치가 마련되어 있는데요, 이것이 소프트웨어와 사람의 소통을 위한 **UI( user interface)**입니다.

하지만 이외에도 우리 눈에 보이지 않는 수많은 요청과 정보 교환이 이루어지고 있습니다.

이런 기계 - 기계 사이에서도 소통이 가능한 창구가 필요합니다.

 

 

 

특정 형식에 맞춰서 해당 주소로 정보를 요청하면 특정 양식으로 답이 온다는 공개된 메뉴얼이 있으면 누구든 이걸 참조해서 기상청 정보를 활용하는 소프트웨어를 만들 수 있다.

 ❓ 공개된 매뉴얼이 있다면 누구든지 이걸 활용해서 특정 정보를 사용한 서비스를 만들수 있지 않을까요?

 

 

API !

 

‼️ 소프트웨어가 다른 소프트웨어로부터 지정된 형식으로 요청, 명령을 받을 수 있는 수단을 API라고 한다.

 

 

2. REST 란?

2-1. REST란?

Rest Api는 Rest 라는 형식의 API를 말합니다. 이런 이유 때문에 REST API 를 종종 RESTful API라고도 합니다.

여기서 중요한건 형식이라는 점입니다. 그래서 어떤 언어/ 프레임 워크를 사용하더라도 이 형식에 맞춰서 기능을 구현하면 됩니다.

 

2-2. REST의 목적

→이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것

→API의 이해도 및 호환성을 높이는 것

 

2-3. REST 구성요소 - 자원/ 행위/ 표현

 

1)자원(Resource) : URI - 자원을 구조와 함께 나타내는 형태의 구분자 (URI는 동사가 아닌 명사로 구성!)

 

ex) - 상품 리스트 가져오기 /api/ goods

      - 상품 정보 가져오기 /api/ goods/ {id}

      - 상품 가격 정보 가져오기 /api/ goods/ {id}/ price.  

      - 특정 가격에 해당하는 상품정보 가져오기 /api/ goods/ {id}/ price? original≥ 1000

 

⇒자원에서 api/goods-list. 와 같이 설계하지 않는 이유는.

uri는 리소스만 식별하고 리소스에 대한 행위들은 아래있는 HTTP 메서드로 나타낼수 있기 때문입니다.

 

2)행위(Verb) : HTTP Method

 

누구든지 각 요청의 의도를 쉽게 파악할 수 있도록 RESTful하게 API를 만들기 위해서는 이들을 목적에 따라 구분해서 사용해야 한다.

 

3)표현(Representation of Resource)

→잘 설계된 REST API는 URI, 즉 요청만 잘 설계된 것이 아닌 그 리소스에 대한 응답을 잘 내어주는 것까지 포함되어야 합니다.

왜냐하면 정확한 응답의 상태코드만으로도 많은 정보를 전달할 수 있기 때문에 응답의 상태코드 값을 명확히 돌려주는 것은 생각보다 중요한 일이 될 수 있습니다.

 

<상태코드 예시>

상태코드	내용
200번대	성공
200	Ok, 클라이언트의 요청을 정상적으로 수행함.
204	No Content, 요청은 성공했으나 응답할 콘텐츠가 없음.
300번대	리다이렉션
400번대	클라이언트 오류
400	Bad Request, 클라이언트가 올바르지 못한 요청을 보냄.
401	Unauthorized, 인증 혹은 승인되지 않은 접근(로그인을 하지 않아 페이지를 열 권한이 없음)
404	Not found, 찾을 수 없는 페이지, 주소를 잘 못 입력했을 때 사용함. 인증받지 않은 클라이언트로 부터 리소스를 숨기기 위해 403 대신에 사용할 수도 있음. (해커들의 공격을 방지하고자 페이지가 없는 것처럼 위장하는 경우)
408	Request Timeout, 요청 시간이 초과됨.
500번대	서버오류
502	Bad Gateway, 서버로 가능 요청이 중간에서 유실된 경우.

 

 

2-4. REST API 디자인 가이드

1️⃣  첫 번째, URI는 정보의 자원을 표현해야 한다.

2️⃣  두 번째, 자원에 대한 행위는 HTTP Method로 표현한다.

 

 

2-5. REST 특징

→ 요청의 모습 자체로 내용 추론이 가능!

 👉🏻 (예시)

*HTTP ⇒ https://adventure-works.com/orders/1 ⇒ [주문과 관련된 요청이구나!]

*JSON ⇒ {"orderId":1,"orderValue":99.90,"productId":1,"quantity":1}

 

우리가 만들고자 하는 서비스에서 기능 자체만 중요하게 생각한다면, REST고 뭐고 생각할 필요 없이 기능만 동작하게 만들면 그만이다.

하지만 문제는 이 서비스를 개발자 혼자서 만드는게 아니라는 점이다.

지금은 혼자라도 나중에 인계받을 개발자나, 이 API를 활용해서 다른 제품을 만들 개발자들은 일하기 힘들어질 것이다. 🤮

 

 

결론

⇒REST API는 HTTP 요청을 보낼때

어떤 URI에 어떤 메서드를 사용할지 정해놓은 약속을 말한다.

이것은 형식이기 때문에 기술에 구애받지 않는다.

 

 

🛑  조금더 자세한 정보를 원하시면 아래 키워드로 구글링 해보세요! 🤓

 

 

 

 

 

출처

https://velog.io/@pjh612/REST-API-URI-규칙

https://www.ibm.com/kr-ko/cloud/learn/rest-apis

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

https://loy124.tistory.com/368

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

https://devuna.tistory.com/78