RESTful API 설계 문제
-- Omer Rana의 Unsplash님 사진
최근에 실제 프로덕션 시스템에서 작업할 때 나는 스스로에게 질문을 던졌습니다.
REST API는 현재 아키텍처 선택에 의해 제한되어야 합니까?
문제를 설명하기 위해 예제를 발명했습니다.
자동차 렌트에 사용되는 시스템을 상상해 봅시다. 사업은 일종의 "자동차 렌탈"을 위한 에어비앤비입니다. 자동차를 렌트하는 소기업은 시스템에 자신의 자리를 등록하여 더 넓은 범위의 잠재 고객에게 접근할 수 있습니다. 시스템을 통해 차량을 관리할 수 있지만 다른 렌트카는 관리할 수 없습니다.
우리가 신생 기업이고 시스템을 구축한다고 상상해 봅시다. 소규모로 시작하여 관계형 데이터베이스를 사용하여 모든 자동차를 단일 테이블에 저장합니다. 각 차량은 이 표에서 고유 ID로 식별됩니다.
시스템용 RESTful API를 내보내려고 합니다.
무엇보다도 한 지점에서 모든 자동차를 탐색하고 단일 자동차 세부 정보를 얻으려면 API가 필요합니다.
한 지점에 있는 모든 차량을 나열하는 API는 다음과 같습니다.
GET /spots/{spotId}/cars
자동차의 ID를 얻을 수 있는 자동차 목록을 반환합니다.
ID로 자동차를 가져오는 API는 다음과 같습니다.
GET /spots/{spotId}/cars/{carId}
또는
GET /cars/{carId}
우리는 API 디자인의 모범 사례에 부합하기를 원했기 때문에 더 긴 경로를 따르기로 결정했습니다. 왜냐하면 자동차는 단독으로 존재할 수 없고 항상 지정된 지점에 속해 있는 리소스이기 때문입니다. 경로
/spots/{spotId}/cars
는 관계를 명확하게 설명합니다.그러나 경로의
spotId
는 중복됩니다.단일 테이블에 모든 자동차가 있고 자동차 ID를 알고 있으므로
/spots/{spotId}/cars
끝점에서 가져왔기 때문에 실제로 필요한 유일한 변수는 carId
입니다.물론 우리의 관계형 데이터베이스에서 우리는 자동차에서 지점까지의 관계를 갖게 될 것이고 쿼리에
spotId
를 추가할 수 있지만 중요하지는 않습니다.예를 들어 다음과 같은 쿼리가 있을 수 있습니다.
select c.* from cars c inner join spots s
on s.id = c.spot_id
where s.id = :spotId and c.id = :carId
그러나 다음과 같은 결과를 얻습니다.
select * from cars
where id = :carId
그렇다면 끝점 경로로
/spots/{spotId}/cars/{carId}
또는 /cars/{carId}
를 사용해야 합니까?나는 그것에 대해 생각해 왔으며 두 옵션 모두 장단점이 있습니다. 앞에서 언급했듯이 API 관점의 의미론에서는 긴 것이 더 적절하게 들리지만, 백엔드 아키텍처의 현재 상태에서 사용하고 구현하기에는 짧은 것이 더 쉽습니다.
우리 서비스의 진화에 대해 생각해보면 cars 테이블을 각 지점별로 분리하고 싶을 수도 있다고 상상할 수 있습니다. 이는 데이터 양이 증가하거나 데이터베이스를 배포하고 각 지점 근처에 여러 인스턴스를 설정하려는 경우(더 나은 성능 및 확장을 위해) 발생할 수 있습니다. 그런 다음 각 자동차는 고유하지만 단일 DB 인스턴스(또는 지정된 지점의 특정 위치에 있는 인스턴스 클러스터를 고려하는 경우 인스턴스) 내에 있습니다. 그러면 우리는
spotId
와 carId
의 쌍으로만 자동차를 구별할 수 있었고 더 긴 API 경로가 더 의미가 있을 것입니다.마침내 나는 스스로에게 이렇게 대답했다.
API는 아직 없습니다. 아키텍처가 진화하면 API도 진화합니다.
현재 이치에 맞고 단순한 것(
/cars/{id}
)이 미래에는 더 이상 적용되지 않을 수 있습니다. 앞으로 자동차 보관소를 각 렌터카 지점에 대해 별도의 테이블/데이터베이스로 분할해야 하는 경우 새 API는 다음과 같을 수 있습니다. /spots/{spotId}/cars/{carId}
. 반면에 이것은 결코 일어나지 않을 수 있으며 Donald Knuth가 "조기 최적화는 모든 악의 근원입니다"라고 말하곤 했습니다.문제에 대한 답은 무엇입니까? 더 많은 생각이 있으시면 저와 다른 독자들과 의견을 나누십시오.
Reference
이 문제에 관하여(RESTful API 설계 문제), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/piczmar_0/restful-api-design-concerns-n8j텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)