컨벤션에서 DB 테이블 이름은 단수이지만 RESTful 리소스는 복수 여야한다고 말하는 이유는 무엇입니까?

최소한 SQL에서 데이터베이스 테이블 이름은 단수 여야한다는 것이 꽤 확립 된 규칙입니다. SELECT * FROM user;참조 이 질문과 토론을 .

RESTful API 자원 이름이 복수 여야한다는 꽤 확립 된 규칙이기도합니다. GET /users/123그리고 이것을POST /users 보십시오 .

가장 간단한 데이터베이스 기반 API에서 URL의 리소스 이름은 테이블이되고 URL 및 요청 / 응답 본문의 데이터 요소는 DB의 열에 직접 매핑됩니다. 개념적 으로이 이론적 API를 통한 데이터 작업과 SQL을 통한 데이터 작업의 차이점은 없습니다. 그리고 그로 인해 명명 규칙의 차이점 user과 users이해가되지 않습니다.

개념적으로 REST API와 SQL이 동일한 작업을 수행 할 때 복수화의 차이점을 어떻게 정당화 할 수 있습니까?

— 스미 텔리
소스

더 없습니다 하나의 DB 테이블 이름이나 모두가 따른다고 편안하고 자원 이름의 규칙. 반대로 많은 규칙이있을 수 있습니다. 일부가 충돌하는 것은 놀라운 일이 아닙니다.

— Eric King

그러한 확립 된 협약은 없습니다. 저는 항상 복수 테이블 이름을 사용했습니다. 사용자 , 계정 등은 하나 이상을 보유하고 있기 때문입니다.

— GrandmasterB

@GrandmasterB 협약은 존재하며, 관계가 여러 가지 목록이 아닌 목록이기 때문에 "관계"(관계와 혼동되지 않는 테이블이 됨)가 단일 이름을 갖는 Codd의 관계형 모델에서 유래되었습니다. 각 관계는 하나의 목록입니다. 관계 모델 도메인 엔터티 Codd의 관계형 모델에서 엔티티 이름은 단수입니다. 존재하지 않는다고 말하는 문헌이 풍부합니다. 그러나 원하는 경우 여러 이름을 사용하는 것이 좋습니다.

— Tulains Córdova

@ user61852 규칙에 따라 사용할 수있는 사람들이 있습니다. 그러나이 질문에 제시된 것처럼 낙타 케이스 또는 마크 다운과 같은 방식으로 광범위하게 준수되는 업계 협약은 결코 아닙니다.

— GrandmasterB

또한 REST는 데이터베이스 액세스 프로토콜이 아닙니다. DB 이름 지정 규칙 (어느 쪽이든 상관 없음)과 URL 이름 지정 규칙 (어느 쪽이든 상관 없음)이 서로 달라야 할 이유는 없습니다. 매우 다른 두 도메인. 왜 데이터베이스가 단일을 사용하고 URL이 복수를 사용하는지에 대해 숙고하는 것이 더 이상 합리적이지 않습니다. 데이터베이스가 단일을 사용하는 이유를 숙고하는 것보다 내 시스템 관리자가 파일 시스템 디렉토리를 복수로 명명합니다. 잘못 설계된 웹 프레임 워크에는 REST가 DB 액세스와 관련이 있다고 생각하는 사람들이 있지만 그렇지 않습니다.

— Cormac Mulhall

답변:

REST 사양 (원하는 수준)은 데이터베이스 액세스로 설계되지 않았습니다. API 액세스에 표준화를 시도하고 있습니다. 언급 된 SQL 규칙 (사용 여부에 관계없이)은 API 액세스를 염두에두고 설계되지 않았습니다. SQL 쿼리를 작성하기위한 것입니다.

따라서 여기서 풀어야 할 문제는 API가 데이터베이스에 직접 매핑된다는 개념적인 이해입니다. 우리는 이것을 적어도 2009 년까지 반 패턴으로 묘사 할 수 있습니다 .

이것이 나쁜 주요한 이유는 무엇입니까? "이 작업이 데이터에 어떤 영향을 줍니까?"를 설명하는 코드 클라이언트 코드가됩니다 .

이것은 API에 끔찍한 영향을 미칩니다. (전체 목록이 아님)

API와의 통합이 어렵습니다

다음과 같이 문서화 된 새 사용자를 만드는 단계를 상상합니다.

POST /users { .. }
POST /usersettings { .. } 일부 기본값
POST /confirmemails { .. }

그러나 2 단계의 실패를 어떻게 처리합니까? 동일한 처리 로직이 API의 다른 클라이언트에 복사-파스타되는 횟수는 몇 번입니까?

이러한 데이터 작업은 종종 클라이언트에서 단일 작업으로 시작되는 동안 서버 측에서 쉽게 시퀀싱 할 수 있습니다. 예 POST /newusersetup. DBA는이를 스토어드 프로 시저로 인식 할 수 있지만 API 조작은 데이터베이스 이상의 영향을 미칠 수 있습니다.

API 보안이 절망의 블랙홀이 됨

두 개의 사용자 계정을 병합해야한다고 가정 해 봅시다.

GET /users/1
PUT /users/2 { .. }
DELETE /users/1

사용자 삭제를 허용하지 않고 병합 기능을 허용하도록 사용자 권한을 어떻게 설정 하시겠습니까? 존재 하는 DELETE /users/1경우 /usersettings에도 사용자를 삭제하는 것이 공정 합니까?

API 작업은 시스템에서 여러 변경을 유발할 수있는 데이터베이스 수준보다 높은 수준의 작업으로 간주해야합니다.

유지 보수가 어려워 짐

... 클라이언트는 데이터베이스 구조에 의존하기 때문입니다.

이 시나리오에 대한 나의 경험을 바탕으로 :

기존 테이블 / 열의 이름을 바꾸거나 제거 할 수 없습니다. 기능 이름이 잘못되었거나 더 이상 사용되지 않는 경우에도 마찬가지입니다. 클라이언트가 고장날 것입니다.
새로운 기능은 기존 데이터 구조를 변경할 수 없으므로 데이터와 기능이 기존 기능과 전체적으로 속해있는 경우에도 인위적으로 분리됩니다.
코드베이스는 조각화, 혼란스러운 이름 및 안전하게 제거 할 수없는 수하물로 인해 점차 이해하기 어려워집니다.
사소한 변경을 제외한 모든 변경은 점점 더 위험하고 시간이 많이 걸립니다.
시스템이 정체되어 결국 교체됩니다.

데이터베이스 구조를 클라이언트, 특히 개발 제어 권한이없는 클라이언트에 직접 노출시키지 마십시오. API를 사용하여 클라이언트를 유효한 조작으로 좁히십시오.

따라서 API를 데이터베이스에 직접 인터페이스로 사용하는 경우 복수화는 걱정할 필요가 없습니다. 버리기 실험 이외의 경우 API가 나타내는 높은 수준의 작업을 결정하는 데 시간을 할애하는 것이 좋습니다. 그런 식으로 보면 복수화 된 API 엔티티 이름과 단일 SQL 엔티티 이름간에 충돌이 없습니다. 그들은 다른 이유로 거기에 있습니다.

— 케이시 스피크 만
소스

다른 질문에 답하십시오. OP는 API와 DB 엔티티의 직접적인 연관을 의미하지 않으며 두 컨텍스트에서 일부 엔티티가 존재하기 만합니다.

— Basilevs

질문에 대한 답변을 자유롭게 올리십시오.

— Kasey Speakman

@Basilevs 사실 이것은 이것이 질문에 대한 답변이라고 생각합니다. 때로는 잘못된 가정을 중심으로 질문을 구성하면 답변이 간접적으로 나타날 수 있습니다. "모두 상황에서 일부 개체의 존재는" 그들이 어떤이 아닌 다른 사람 사이에 일대일 대응을 의미 같은 기관이다 의미한다. 복잡한 데이터 모델에 대한 이러한 API의 대응은 결함있는 설계를 의미합니다.

— Aluan Haddad

이것들 중에 SpringData Rest 사용을 중단 한 많은 이유가 있습니다.

— 세바스티안 반 덴 브 ek

REST API와 SQL이 "같은 작업을 수행하지 않습니다"

OP는 묻습니다.

개념적으로 REST API와 SQL이 동일한 작업을 수행 할 때 복수화의 차이점을 어떻게 정당화 할 수 있습니까?

아,하지만 메뚜기, 그것은 수 표시 평온한 인터페이스와 SQL 테이블 "같은 일을하고있다"고하지만, 좋은 프로그래밍 위생 항상 중간층가 있다는 것을 우리에게 알려줍니다 그 REST API와 데이터베이스 사이에서 중재. 이 점을 무시하는 것은 소프트웨어 깨달음의 길에서 벗어나는 것입니다! :)

따라서 RESTful API 및 SQL 테이블은 고유 한 관용적 명명 규칙을 행복하게 따를 수 있습니다.

— fearless_fool
소스