API - 다중 요청과 사용자 역할 분리

Question

저는 단일 페이지 애플리케이션의 프런트엔드 작업을 하고 있으며 학생 수를 나열해야 합니다.각 학생은 특정에 연결되어 있습니다 user_id 이는 내가 수행할 때 모든 사용자 역할(수퍼관리자, 관리자, 교수, 학생)에 대해 API가 반환하는 것입니다. GET /students:

{
  address: null
  class_id: 184
  class_name: "I B"
  date_of_birth: null
  first_name: "first"
  gender: null
  grade: 1
  id: 192
  last_name: "last"
  nationality: null
  place_of_birth: null
  ranking_by_class: 0
  ranking_by_school: 0
  registration_number: null
  user_id: 238
}

저는 각 학생의 추가 데이터가 필요한 순간에 최고 관리자 역할을 수행하고 있습니다(subscription_type), 다음에서만 사용할 수 있습니다. GET /users/:id

따라서 한 페이지에 20~30명의 학생을 나열할 때 다음을 통해 GET /students/, 을(를) 얻으려면 subscription_type, 또한 학생당 하나씩 20~30개의 추가 요청을 수행해야 합니다.

이에 대해 API 담당자와 이야기를 나눴는데 추가 데이터를 students "RESTful 방식이 아닙니다.", "응답 시간이 더욱 느려집니다.", "30개의 추가 요청이 큰 덩어리보다 가볍습니다."

API 작업에 대해 아무것도 모르기 때문에 실제로 말할 수는 없지만 페이지 로드 시 30개의 요청이 터무니없다고 생각하는 것이 미친 걸까요?

그럼 다음은 무엇입니까?계속해서 추가 요청을 수행해야 합니까?각 사용자 역할에 대한 응답을 분리하고 각 역할에 필요한 것만 포함해야 합니까?이것은 올바른 방법 이걸 처리하는 게 어때?

Answer 1

엄밀히 말하면 API 사용자는 정확하지만 RESTful 복음을 너무 엄격하게 따르면 순수 구현으로 인해 발생하는 1+N 문제와 같은 비효율성을 초래할 수 있습니다.RESTful 디자인의 핵심 개념은 리소스가 도메인 개체에 직접 매핑될 필요가 없다는 것입니다.리소스를 설계할 때 사용 시나리오를 살펴봐야 합니다.최고 관리자 시나리오에서는 클라이언트가 다음 컬렉션을 요청하는 것처럼 들립니다. students 또한 일반적으로 또는 항상 다음의 데이터가 필요합니다. users, 구체적으로 subscription_type.개체 모델은 그래야 하는 대로 명확하게 정규화되어 있지만 리소스가 반드시 그래야 하거나 항상 그래야 한다고 말하는 것은 아닙니다.

유사한 시나리오를 보다 효율적으로 만들기 위해 사용한 몇 가지 다른 패턴이 있습니다.적용되는 항목(둘 중 하나)은 클라이언트가 리소스를 소비하는 방식에 따라 다릅니다.

복합 자원

이는 두 개 이상의 도메인 개체 전체 또는 일부의 조합입니다(예: student 그리고 user)을 단일 리소스로 변환합니다.

모두 이후 students 아마도 또한 users, 적절하게 학생 리소스에 사용자 데이터의 전부 또는 일부를 포함할 수 있습니다.

GET /students

{
  address: null
  class_id: 184
  class_name: "I B"
  date_of_birth: null
  first_name: "first"
  gender: null
  grade: 1
  id: 192
  last_name: "last"
  nationality: null
  place_of_birth: null
  ranking_by_class: 0
  ranking_by_school: 0
  registration_number: null
  user_id: 238
  subscription_type: "foo"
}

관련 자료

(다른 응답과 유사) 이는 클라이언트가 응답에 관련 리소스가 포함되기를 원함을 나타낼 수 있는 기술입니다.이는 도메인 모델의 "has a" 유형 관계에 특히 유용합니다.이를 통해 클라이언트는 본질적으로 다음을 수행할 수 있습니다. 게으른 로드 또는 열망하는 부하 자원.

GET /students

{
  address: null
  class_id: 184
  class_name: "I B"
  date_of_birth: null
  first_name: "first"
  gender: null
  grade: 1
  id: 192
  last_name: "last"
  nationality: null
  place_of_birth: null
  ranking_by_class: 0
  ranking_by_school: 0
  registration_number: null
  user_id: 238
}

GET /students?include_user=true

{
  address: null
  class_id: 184
  class_name: "I B"
  date_of_birth: null
  first_name: "first"
  gender: null
  grade: 1
  id: 192
  last_name: "last"
  nationality: null
  place_of_birth: null
  ranking_by_class: 0
  ranking_by_school: 0
  registration_number: null
  user_id: 238
  user:
  {
   id: 238
   subscription_type: "foo"
   ...
  }
}

Answer 2

여기에는 두 가지 문제가 있습니다. 하나는 함께 묶어서는 안됩니다. 하나는 인덱스 호출 (/학생)에 대해 각 사용자에 대해 반환 된 데이터이며, 다른 하나는 특정 사용자가 노출 할 수있는 데이터를 결정 해야하는 권한 부여 프로세스입니다. .

데이터 문제와 관련하여 따라야 할 특정 규칙이 없다고 생각합니다.이는 전적으로 앱의 요구 사항에 따라 다릅니다.일반적으로 subscribe_type 필드가 불필요한 경우 특정 요청에 필요함을 나타내기 위해 쿼리 매개변수(예: 'include_extra_data=1')를 전달하는 것을 고려할 수 있습니다. 이 경우 기본적으로 반환되지 않습니다.

인증 문제 관련 - 요청 시 요청한 데이터와 완전히 연결이 끊어져야 합니다.서버는 사용자 ID에 따라 사용자에게 표시되는 데이터를 결정할 수 있어야 합니다.(당신은 확인할 수 있습니다 캔캔젬][1] 가능한 해결책으로).

따라서 두 가지 문제를 결합하면 모든 유형의 사용자가 'include_extra_data' 플래그 유무에 관계없이 '/students' 요청을 할 수 있어야 합니다.서버에서 추가 데이터를 볼 권한이 없는 사용자를 발견하면 두 가지 옵션 중 하나를 선택할 수 있습니다. 즉, 사용자가 볼 수 있도록 허용된 데이터만 반환하거나 '401 무단' 응답을 반환합니다.

두 가지 방법 모두 유효하며 클라이언트 앱에서 응답을 처리하는 방식에 영향을 미칩니다.(저는 개인적으로 후자를 선호합니다. 클라이언트에게 더 설명적이기 때문입니다.)

도움이 되었기를 바랍니다 :)