📌API?
우리가 참 API라는 말을 많이 듣는다. 근데 뭔가 항상 읽을때마다 되게 모호한 개념인 것 같아서 되게 예시를 많이 들어서 이해를 하곤 했는데 다음과 같다고 한다.
API는 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘입니다. 예를 들어, 기상청의 소프트웨어 시스템에는 일일 기상 데이터가 들어 있습니다. 휴대폰의 날씨 앱은 API를 통해 이 시스템과 "대화"하고 휴대폰에 매일 최신 날씨 정보를 표시합니다.
여기서는 두 소프트웨어의 구성 요소가 서로 통신할 수 있게 하는 메커니즘이라고 하는데 기상청의 예시를 들었다. 이게 글로 되있어서 간단하게 정리하면 다음과 같다.
날씨 앱 ------------- API -------------------------- 기상청 소프트웨어 시스템(일일 기상 데이터 포함)
그리고 이런 예시도 있었다.
손님 ----------------- 카운터(API) ----------------------- 주방 손님이 메뉴를 정해서 카운터에 전달하면 카운터가 그 메뉴를 주방에 전달해주고 주방에서는 조리가 완료된 것을 카운터에 전달해 손님에게 주는 이런 통신 중 카운터가 API의 역할을 한다고 하였다.
회원 정보 관리 API를 만들어보자.
🏸 좋은 API URI 설계
우리가 이제 예를 들어서 회원 정보 관리를 하는 API를 만들려고 할 때 다음과 같은 목록이 있다고 하자.
그렇다면 다음과 같이 URI를 설계할 수 있다. 이름의 목적에 따라서 이름을 지었다.
- 회원 목록 조회 :
/read-member-list- 회원 조회 :
/read-member-by-id- 회원 등록 :
/create-member- 회원 수정 :
/update-member- 회원 삭제 :
/delete-member
근데.. 이게 좋은 이름 설계일까? -> NO!
URI설계를 할 때 가장 중요한 것이 리소스를 식별하게 하는 것이라고 한다.
🏸 리소스?
리소스는 우리가 웹 사이트에 접속하거나 API 호출을 할 때, 서버로부터 제공받는 식별 가능한 자원들을 의미합니다.
위 회원 정보 관리와 같은 경우에는 회원이라는 것이 리소스가 된다.
ex) 미네랄을 캐라, 미네랄을 버려라 하는 경우에서는 미네랄이 리소스가 된다.
이런 리소스들을 식별하는 것이 엄청 중요하다고 했는데 어떻게 식별하면 될까?
결론부터 얘기하자면 회원이라는 리소스만 식별을 하면 된다고 한다. 그리고 생각을 해보면 회원 뒤에 있는 키워드들은 다 어떠한 행동을 하는 의미를 가진다. 그래서 이것을 잘 분리하여서 URI를 설계하는 것이 좋은데 이와 같이 말이다.
- 회원 목록 조회 :
/members- 회원 조회 :
/members/{id}- 회원 등록 :
/members/{id}- 회원 수정 :
/members/{id}- 회원 삭제 :
/members/{id}
보통 리소스는 members 처럼 복수형으로 하는 것을 권장한다고 한다.
근데 이렇게 하면 /members/{id} 이렇게 조회,등록,수정,삭제는 동일한데 어떻게 구분을 해줘야될까? 위에서 키워드들이 행동을 의미한다고 하였는데 이 행동에 따라서 구분을 시켜주면 된다. 이것을 행동에 따라 처리를 해주는 걸 HTTP Method라고 하는 것이 도와준다고 하는데 다음 글에서 알아보자.
출처
- 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식(https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC)
- https://aws.amazon.com/ko/what-is/api/
