백엔드 ID가 공개 API이어야합니까?

이 사람의 말을 바탕으로 : http://toddfredrich.com/ids-in-rest-api.html

그가 API 자원을 식별하기 위해 UUID를 사용하는 것이 옳다고 가정합시다. 그런 다음 그런 식으로 구현하려고하면 문제가 발생합니다.

class FooEntity {

    final String id = null;  //auto-generated by my backend (mongodb), not shared
    final UUID uid = UUID.randomUUID();  //the resource id
}

클라이언트와 서버 간에는 데이터베이스 엔터티가 아닌 DTO가 송수신됩니다.

이제 문제는 id더 이상 사용하지 않기 때문에 유용하지 않다는 것입니다. 클라이언트가 요청을 uid하므로 왜 2 id를 처리해야합니까? 그런 다음 시작과 같은 문제로 돌아갑니다. UUID를 기본 키 ( _id) 로 설정 하면 백엔드 ID를 공개합니다.

그 외에도 효율성 주제가 있습니다. ObjectId에 의한 색인 생성이 UUID보다 훨씬 효율적이라는 것을 읽었습니다.

백엔드 ID를 공개하고 있습니다

엔티티가 요청을 통해 리턴 될 때 식별해야하는 다른 방법은 무엇입니까? 그것은 SSN 또는 유사한 식별자보다 완벽하고 합법적입니다. 그것이 Todd가 말하고있는 것입니다. 식별 기술과 엔티티를 중립으로 만드는 것이 맞습니다.

효율성 주제

ObjectId가 훨씬 더 효율적인 경우 두 식별자를 모두 유지할 수 있습니다. 이론적으로 데이터베이스 자동 증 분기 보다 식별자에 UUID 를 사용하는 것이 좋습니다 .

아니요, 데이터베이스가 진행되는 한 내부 구조에 대해서는 외부 API에 노출되지 않습니다. ID는 지능이 없습니다. 그들은 실제 세계에서도 독특하지 않습니다. ID : 47은 어디에나 있습니다. 액세스 할 수 있고 데이터를 조작 할 수있는 엔터티가 있지만이 데이터베이스가 모든 것을 하나의 테이블 또는 10 개로 저장하거나 증분 ID를 PK로 사용하고 FK와 관련이 있는지 여부는 알 수 없습니다.

가능한 경우 GetUserAccountByID (12345)는 누군가 누군가 GetUserAccountByID (12346)를 시도하도록 요청하고 있습니다. 다른 보안 조치로 인해 작동하지 않지만 계정 : 12346에 대한 정보를 요청하여 회사를 사회적으로 해킹하려고 시도하거나 시도하지 마십시오. DBA에 전화하지 않고 응답;)

따라서 GUID를 만들지 만 전화 번호 또는 전자 메일 주소와 같이 적합하거나 다른 자연 키가 표시됩니다. 일부 병합 데이터 시도에서 모호한 복사 및 붙여 넣기 시도를 피하려면 테이블의 필드에 고유 제한 조건을 설정하십시오.

중복되지 않습니다. 두 필드는 다른 목적으로 사용됩니다.

효율성 id 대 UUID에 대해, 각각 수백만 개의 레코드를 갖는 다중 테이블을 포함하는 다중 조인이없는 한, 그렇게 큰 차이는 없습니다. UUID를 사용하면 서버 측에서 바로 확인 / 적용하지 않으면 응용 프로그램을 스크랩하기가 훨씬 어려워집니다.

• GET [...] / 1
• GET [...] / 2

ID를 사용할 때 매우 쉽습니다. UUID를 대신 사용하면 스크레이퍼 옵션이 적습니다.

ID는 애플리케이션의 데이터베이스 인스턴스 내부에있는 것으로 볼 수 있습니다. 이 문장에는 세 가지 중요한 단어가 있습니다.

• 응용 프로그램 : 모델이기 때문에 해당 응용 프로그램에서만 테이블을 사용할 수 있습니다.
• 데이터베이스 : 여러 응용 프로그램이 동일한 데이터베이스에 대해 여러 응용 프로그램을 사용한 경우 괜찮습니다.
• 인스턴스 (데이터베이스) : 분산 시스템을 사용하는 경우 id는 서로 상충되며 데이터베이스의 인스턴스를 사용하지 않는 다른 시스템 / 응용 프로그램에는 의미가 없습니다. UUID는 특정 사례에 대한 솔루션입니다.

개인 취향 : 간단한 ID와 고유 한 비즈니스 ID (메일, 로그인 등)를 선호합니다. 따라서 데이터를 교환 해야하는 경우 대상 시스템이 UUID를 처리하지 못할 수 있기 때문에 비즈니스 ID를 사용하지만 고유 한 비즈니스 키를 잘 처리 할 가능성은 거의 없습니다 (절대 결코 말하지 마십시오 ...).