[공식 문서 한글 번역판] xAPI docs 3.0 Communication 톺아보기

이 문서는 Experience API (xAPI)의 데이터 처리, 유효성 검사 및 보안과 관련된 기술적인 측면을 다루며, 학습 기록 제공자(Learning Record Provider, LRP)와 LRS(Learning Record Store) 간의 Statements가 어떻게 전송되는지에 대한 내용을 다룬다. 이 명세의 이 부분에 대한 모든 Details을 완전히 이해해야 하는 것은 아닐 수 있으며, 다양한 기술을 위한 라이브러리가 제공되므로 xAPI를 구현하는 사람들은 현재 산업의 최고 관행을 사용하는 것이 좋다.

1.0 요청
Requests

---

xAPI 추적은 학습 기록 제공자(LRP, 클라이언트)에서 LRS(서버)로의 HTTP 요청을 통해 이루어진다. 이 명세서는 이 통신의 일부 측면에 대한 지침을 제공한다. 지침이 제공되지 않은 경우, xAPI를 구현하는 사람들은 현재 산업의 최고 관행을 사용하는 것이 권장된다.

1.1 HEAD Request Implementation (1.1 HEAD 요청 구현)

Description

LRS는 PUT, POST, GET 및 DELETE 요청에 대한 응답에 관한 동작은 아래 "Resources"에서 Description된다. 모든 GET 요청을 지원하는 Resource는 HEAD도 지원한다. LRS는 HEAD 요청에 대해 실제 문서가 아닌 HTTP 헤더를 사용하여 메타 정보만 반환하여 응답한다.

Rationale

LRS에 접근하는 클라이언트는 특정 Statement가 존재하는지 확인하거나 State, Activity Profile 또는 Agent Profile Resource와 같은 문서의 수정 날짜를 결정해야 할 수 있다. 특히 큰 문서의 경우 수정 날짜를 확인하기 위해 문서 전체를 가져오지 않는 것이 더 효율적이다.

LRS Requirements

• LRS는 메시지 본문(message-body)을 생략해야 한다.
• Content-Length 헤더는 LRS 자원을 낭비하지 않기 위해 생략될 수 있다.

1.2 Headers

Header Parameters

일부 xAPI 데이터 전송에서 사용되는 헤더 Parameter는 표준 HTTP 헤더이다. 다른 Parameter는 이 명세에 특정한다. 다음 요청 헤더는 이 명세서에 Description된 Type의 요청 및 상황 중 일부 또는 모두에서 학습 기록 제공자(LRP)에 의해 사용될 것으로 예상된다.

요청 헤더 (Request Headers)

• Accept
• Accept-Encoding
• Accept-Language
• Authorization
• Content-Type
• Content-Length
• Content-Transfer-Encoding
• If-Match
• If-None-Match
• X-Experience-API-Version

응답 헤더 (Response Headers)

• Content-Type
• Content-Length
• Last-Modified
• ETag
• Status
• X-Experience-API-Version
• X-Experience-API-Consistent-Through

1.3 대체 요청 구문 (Alternate Request Syntax)

Details/Description

xAPI의 목표 중 하나는 도메인 간 추적을 허용하는 것이며, 브라우저 외의 응용 프로그램에서 추적을 활성화하려고 하지만 여전히 브라우저를 지원해야 한다. 예를 들어, 인터넷 익스플로러 8 및 9는 Cross Origin Resource Sharing을 구현하지 않고 자체 Cross Domain Request API를 사용하며 "GET" 및 "POST"만 지원하며 HTTP 헤더 설정을 허용하지 않으므로 위에서 Description한 xAPI를 모두 사용할 수 없다.

Requirements

메소드 (Method):

• 모든 xAPI 요청은 반드시 POST여야 한다.
• 의도된 xAPI 메소드는 "method" 쿼리 문자열 Parameter의 값으로 포함되어야 한다.
• Learning Record Provider(LRP)는 요청에 다른 쿼리 문자열 Parameter를 포함해서는 안 된다.
• 예: http://example.com/xAPI/statements?method=PUT

콘텐츠 (Content):

• xAPI 호출이 콘텐츠를 전송하는 경우, Learning Record Provider(LRP)는 해당 콘텐츠를 URL 인코딩하고 "content"라는 form parameters로 포함해야 한다.
• 학습 기록 저장소(LRS)는 이 콘텐츠를 UTF-8 문자열로 해석해야 한다. 바이너리 데이터 저장은 이 문법에서 지원되지 않는다.

헤더 (Headers):

• Learning Record Provider(LRP)는 이 명세서에서 필요한 모든 헤더 Parameter를 HTTP 헤더의 form parameters로 예상하는 경우, Authorization, X-Experience-API-Version, Content-Type, Content-Length, If-Match, If-None-Match과 같은 Parameter를 포함할 수 있다. Content-Transfer-Encoding에는 해당되지 않는다.
• LRS는 위에서 나열한 form parameters를 헤더 Parameter로 처리해야 한다.
• LRP는 HTTP 헤더에 나열되지 않은 다른 헤더 Parameter를 정상적으로 포함해야 한다.
• 이 Type의 요청에 대해 여전히 Content-Type 헤더를 (HTTP 헤더에) 포함하는 것이 좋다. 값은 'application/x-www-form-urlencoded' 여야 한다.
• Content-Type form parameters는 콘텐츠 form parameters 내의 콘텐츠 Type을 지정해야 한다.
• 이 Type의 요청에 대해 Content-Length 헤더(HTTP 헤더)를 여전히 포함하는 것이 좋다. 이 헤더는 요청 콘텐츠의 전체 길이를 나타낸다.
• Content-Length form parameters는 콘텐츠 form parameters 내의 콘텐츠 길이를 지정해야 하며 따라서 Content-Length 헤더에 나열된 길이보다 낮을 수 있다.

쿼리 문자열 Parameter (Query string parameters):

• "method" 이외의 모든 쿼리 문자열 Parameter는 반드시 동일한 이름의 form parameters로 포함되어야 한다.
• LRS는 "content" 또는 위에서 나열한 헤더 Parameter 이외의 form parameters를 쿼리 문자열 Parameter로 처리해야 한다.

첨부 파일 (Attachments):

• 이 구문을 사용하여 이진 데이터 첨부를 보내는 것은 인코딩과 관련된 문제로 인해 불가능한다. 첨부 파일을 보내려면 Attachments 섹션을 참조.

• LRS는 위에서 Description한 구문을 지원해야 한다.

클라이언트 코드가 LRS와 다른 스킴(HTTP 또는 HTTPS)에 호스팅되는 경우, IE 9 이하 버전에서 HTTP에서 HTTPS 요청을 지원해야 하는 경우를 제외하고는 프록시가 필요하지 않다. 현대 브라우저를 사용하는 경우, 프록시 없이도 HTTP에서 HTTPS로 또는 HTTPS에서 HTTP로 요청할 수 있다. 두 가지 간단한 해결책은 1) 클라이언트 코드가 LRS로 패스스루하는 동일한 스킴에 프록시를 설정하거나 2) 클라이언트 코드와 동일한 스킴에 중간 서버 측 LRS를 호스팅하여 Statements를 대상 LRS로 라우팅하는 것이다.

HTTP를 사용하는 구현을 사용하기 전에 보안 리스크를 심각하게 고려하는 것이 좋다.

1.4 인코딩 (Encoding)

Requirements

• 모든 문자열은 반드시 UTF-8로 인코딩되고 해석되어야 한다.

1.5 콘텐츠 Type (Content Types)

이 명세서 내의 요청과 응답은 보통 application/json 콘텐츠 Type을 사용한다. 예외는 다음과 같다.

• 문서는 어떤 콘텐츠 Type도 가질 수 있다.
• 첨부 파일을 포함할 수 있는 Statement 요청은 multipart/mixed 콘텐츠 Type을 사용한다.

1.5.1 Application/JSON (1.5.1 Application/JSON)

LRS Requirements

• application/json 형식의 문서 Type으로 PUT 또는 POST를 수신할 때, LRS는 첨부 파일 객체가 포함되지 않는 Statements의 배치를 수용해야 한다.
• application/json 형식의 문서 Type으로 PUT 또는 POST를 수신할 때, LRS는 fileUrl이 포함된 Attachment 객체만 있는 Statements의 배치를 수용해야 한다.

1.5.2 Multipart/Mixed

"multipart/mixed" 컨텐츠 Type은 첨부 파일을 포함할 수 있는 요청에 사용된다. 그러나 모든 "multipart/mixed" 요청이 첨부 파일을 포함한다는 의미는 아니다.

첨부 파일 교환 절차 (Procedure For The Exchange Of Attachments)

• 첨부 파일을 포함하거나 포함하지 않은 Statement 요청은 아래에 Description된 대로 해석된다.
• Statement는 Content-Type이 "multipart/mixed"로 전송된다. 첨부 파일이 있는 경우 이러한 전송의 끝에 배치된다.
• LRS는 첫 번째 부분의 정보를 기반으로 Statement를 수락 또는 거부한다.
• 요청을 수락하는 경우 첨부 파일의 원시 데이터를 Attachment 헤더의 SHA-2와 비교하여 일치하는 경우에만 수행한다. 다른 방법으로 일치하지 않아야 한다.

진술문 일괄 전송을 위한 Requirements (Requirements for Attachment Statement Batches)

첨부 파일을 포함하는 Statement 일괄 처리 요청, Statement 결과 또는 단일 Statement는 다음 기준 중 하나를 충족해야 한다:

·       application/json Type이어야 하며 "attachments" 필터가 false인 경우를 제외하고 모든 첨부 파일에 대한 fileUrl을 포함해야 한다.

• RFC 2046의 "multipart/mixed" 정의를 준수해야 하며 다음을 포함해야 한다:

LRS Requirements

• 클라이언트(요청하는 측)가 요청한 경우에만 LRS는 위에서 Description한 전송 형식의 첨부 파일을 포함해야 한다(Statement Resource 참조).
• LRS는 Attachments를 요청하지 않고 다른 LRS에서 Statement를 가져오면 안 된다.
• LRS는 다른 LRS에 Statement를 푸시할 때, 받은 첨부 파일 데이터(있는 경우)를 포함해야 한다.
• LRS는 "multipart/mixed" Type의 문서를 받았을 때, 위에서 Description한 전송 형식의 첨부 파일을 포함하는 Statement를 수락해야 한다.
• "multipart/mixed" Type의 문서를 받았을 때, 첨부 파일이 파일 URL을 포함하지 않거나 수신된 첨부 파일 부분과 SHA-2를 기반으로 일치하지 않는 Statement를 거부해야 한다.
• "multipart/mixed" Type의 문서를 받았을 때, 첨부 파일 부분에 대해 Content-Transfer-Encoding을 binary로 가정해야 한다.
• LRS는 구성된 크기를 초과하는 (일괄 처리된) Statement를 거부할 수 있다.
• "multipart/mixed" Type의 문서를 받았을 때, LRS는 첨부 파일 객체를 포함하지 않는 Statement 일괄 처리를 받아들이는 것이 좋다.
• "multipart/mixed" Type의 문서를 받았을 때, LRS는 fileUrl이 포함된 첨부 파일 객체만 포함하는 Statement를 받아들일 것이 좋다.

참고: "mime/multipart" 형식을 사용하는 Statement 일괄 처리가 첨부 파일을 포함해야 하는 Requirements은 없다.

학습 기록 제공자 Requirements (Learning Record Provider Requirements)

• 학습 기록 제공자는 위에서 Description한 방식대로 Attachments를 포함하는 Statements를 보낼 수 있다.
• POST를 사용하는 경우 일부 또는 모든 Attachments가 있는 여러 Statements를 보낼 수 있다.
• "multipart/mixed" 형식에 기반하지 않고 fileUrl이 있는 모든 첨부 파일 객체를 포함하는 application/json Type의 일괄 처리를 보낼 수 있다.
• 학습 기록 제공자는 "sha2" Properties을 채우기 위해 SHA-256, SHA-384 또는 SHA-512를 사용해야 한다.

파일 URL (File URL)

• 파일 URL은 첨부 파일을 받을 위치를 제공하기 위한 것이다. 그러나 첨부 파일의 소유자가 영구히 해당 위치에서 첨부 파일 데이터를 사용할 필요는 없으며, 보안 제한 없이 첨부 파일을 공개할 필요도 없다.
• 첨부 파일 데이터는 fileUrl에 표시된 URL에서 검색 가능해야 한다.
• 첨부 파일의 소유자는 언제든지 이 URL에서 첨부 파일 데이터를 제공하지 않을 수 있다.
• 이 URL에서 첨부 파일 데이터에 액세스하려는 사용자에게 보안 제한이 적용될 수 있다.
• 첨부 파일을 사용할 때 첨부 파일 데이터의 제공 기간 및 호스팅된 첨부 파일에 적용되는 보안 제한은 이 명세서의 범위를 벗어난다.

이것은 Attachments 및 해당 Requirements에 대한 Description이다. Attachments를 사용하는 xAPI 구현자 및 학습 기록 제공자에게 유용한 정보이다.

Example

다음은 매우 간단한 첨부 파일을 포함하는 Statement의 예다. 다음 사항에 유의해야 한다.

• 샘플에서 경계(boundary)는 유효한 문자 클래스를 보여 주기 위해 선택됐다.
• 선택한 경계는 모든 부분에서 나타나지 않는다.
• 가독성을 위해 샘플 첨부 파일은 'text/plain' Type이다. 이진 Type인 'image/jpeg'와 같은 경우에도 인코딩을 수행하지 않으며 원시 옥텟이 포함된다.
• RFC 2046에 따라 경계는 <CRLF> 다음에 --와 헤더에서 선언된 경계 문자열이 따라와야 한다.

참고: 이러한 메시지를 작성하거나 구문 분석할 때 <CRLF>을 잊으면 안된다.

헤더 (Headers):

Content-Type: multipart/mixed; boundary="abcABC0123'()+_,-./:=?" X-Experience-API-Version:1.0.0

콘텐츠 (Content):

--abcABC0123'()+_,-./:=? Content-Type:application/json   {     "actor": {         "mbox": "mailto:sample.agent@example.com",         "name": "Sample Agent",         "objectType": "Agent"     },     "verb": {         "id": "http://adlnet.gov/expapi/verbs/answered",         "display": {             "en-US": "answered"         }     },     "object": {         "id": "http://www.example.com/tincan/activities/multipart",         "objectType": "Activity",         "definition": {             "name": {                 "en-US": "Multi Part Activity"             },             "description": {                 "en-US": "Multi Part Activity Description"             }         }     },     "attachments": [         {             "usageType": "http://example.com/attachment-usage/test",             "display": { "en-US": "A test attachment" },             "description": { "en-US": "A test attachment (description)" },             "contentType": "text/plain; charset=ascii",             "length": 27,             "sha2": "495395e777cd98da653df9615d09c0fd6bb2f8d4788394cd53c56a3bfdcd848a"         }     ] } --abcABC0123'()+_,-./:=? Content-Type:text/plain Content-Transfer-Encoding:binary X-Experience-API-Hash:495395e777cd98da653df9615d09c0fd6bb2f8d4788394cd53c56a3bfdcd848a   here is a simple attachment --abcABC0123'()+_,-./:=?--

2.0 자원
Resources

---

LRS(학습 기록 저장소)는 이 섹션에서 Description된 Resource에 대한 RESTful HTTP 메서드를 통해 상호 작용된다. Statement Resource는 학습 기록을 추적하는 데 독립적으로 사용될 수 있다. 다른 Resource는 추가 기능을 제공한다.

LRS는 이 섹션에서 Description된 모든 Resource를 지원해야 한다. 또한 LRS가 아닌 도구도 이 섹션에서 Description된 하나 이상의 Resource와 메서드의 LRS Requirements을 따르도록 선택할 수 있다. 예를 들어, 도구는 LRS에서 전달된 입력 Statements를 수신하기 위해 POST Statements를 구현할 수 있다. 그러한 시스템은 LRS 또는 '부분 LRS'로 간주되지 않으며, 그저 LRS가 아니다.

참고: 명세서에서 제공된 예제 엔드포인트에서 xAPI Resource가 위치한 모든 경우에 대해 http://example.com/xAPI/는 LRS의 예제 기본 엔드포인트이다. 이것 이후의 IRI 구문은 사용되는 특정 Resource를 나타낸다. 모든 엔드포인트의 전체 목록은 부록 B: 모든 Resource 표에 포함되어 있다.

Requirements

• LRS는 이 섹션에서 Description된 모든 Resource를 지원해야 한다.
• LRS가 OAuth 1.0을 구현하는 경우 OAuth 승인 범위(OAuth Authorization Scope)에서 Description된 모든 OAuth Resource도 지원해야 한다.
• LRS는 이 명세서에서 Description되지 않은 추가 Resource를 지원할 수 있다.
• 현재 및 미래 버전의 이 명세서는 extensions/로 시작하는 경로 세그먼트를 정의하지 않을 것이며, 이 명세서에 정의되지 않은 추가 Resource를 지원하는 LRS는 경로 세그먼트를 extensions/로 시작하도록 해야 한다.

2.1 Statement Resource

Description

Experience API의 기본 통신 메커니즘이다.

2.1.1 PUT Statements

Details

예제 엔드포인트: http://example.com/xAPI/statements

주어진 ID를 가진 단일 Statement를 저장한다. POST를 사용하여 단일 Statement를 저장하는 데도 사용할 수 있다.

내용(Content): 저장할 Statement 객체이다.

반환값(Returns): 204 No Content

Parameter	타입	기본값	Description	필수 여부
statementId	문자열		레코드할 Statement의 ID	필수

LRS Requirements

• LRS는 저장된 Statements를 검색할 수 있도록 하기 전에 응답할 수 있다.
• LRS는 StatementId를 이미 가지고 있는 Statement를 받았을 때 그 기반으로 State를 수정해서는 안된다. 409 Conflict 또는 204 No Content로 응답하더라도 Statement나 다른 객체를 수정해서는 안된다.
• LRS가 StatementId를 이미 가지고 있는 Statement를 받으면 받은 Statement가 기존 Statement와 일치하는지 확인하고 일치하지 않으면 409 Conflict를 반환하는 것이 좋다. Statement comparison requirements을 참조.
• LRS가 동일한 ID를 가진 두 개 이상의 Statement를 포함하는 Statement 일괄 처리를 받으면 해당 일괄 처리를 거부하고 400 Bad Request를 반환하는 것이 좋다.

Learning Record Provider Requirements

• Learning Record Provider는 PUT 대신 Statement "id" Properties을 포함하여 Statements를 POST해야 한다.
• Statements를 PUT할 때 Statement의 "id" Properties을 사용해야 한다.
• 제공된 경우 Statement의 "id" Properties은 요청의 "statementId" Parameter와 일치해야 한다.

2.1.2 POST Statements

Details

예제 엔드포인트: http://example.com/xAPI/statements

Statement 또는 Statement 집합을 저장한다.

내용(Content): 저장할 Statement 배열 또는 단일 Statement이다.

반환값(Returns): 저장된 Statements와 동일한 순서로 Statement ID(UUID) 배열을 반환한다.

Requirements

• LRS는 저장된 Statements를 검색할 수 있도록 하기 전에 응답할 수 있다.
• Query 문자열에 제한이 있는 경우 GET Statements를 POST 및 form Parameter를 사용하여 호출할 수 있다. 자세한 내용은 대체 요청 구문(Alternate Request Syntax)을 참조.
• LRS는 전달된 Parameter를 기반으로 Statement를 추가하거나 Statements 목록을 나열하기 위해 POST를 구분해야 한다. 자세한 내용은 대체 요청 구문(Alternate Request Syntax)을 참조.
• LRS는 StatementId를 이미 가지고 있는 Statement를 받았을 때 그 기반으로 State를 수정해서는 안된다. 409 Conflict 또는 204 No Content로 응답하더라도 Statement나 다른 객체를 수정해서는 안된다.
• LRS가 StatementId를 이미 가지고 있는 Statement를 받으면 받은 Statement가 기존 Statement와 일치하는지 확인하고 일치하지 않으면 409 Conflict를 반환하는 것이 좋다. Statement comparison requirements을 참조.
• LRS가 동일한 ID를 가진 두 개 이상의 Statement를 포함하는 Statement 일괄 처리를 받으면 해당 일괄 처리를 거부하고 400 Bad Request를 반환하는 것이 좋다.

2.1.3 GET 문

Details 예제 엔드포인트: http://example.com/xAPI/statements

이 방법은 단일 Statement 또는 다수의 Statements를 가져오기 위해 호출된다. statementId 또는 voidedStatementId Parameter가 지정된 경우 단일 Statement가 반환된다.

그렇지 않으면 다음과 같이 반환된다: StatementResult 개체, "저장된" 시간을 기준으로 역순으로 정렬된 Statements 목록, 권한 및 최대 목록 길이에 따라 달라집니다. 추가 결과가 있는 경우 이를 검색하기 위한 IRL이 StatementResult 개체에 포함된다.

내용(Content): None

반환값(Returns): 200 OK, Statement 또는 Statement Result

Parameter	Type	Default	Description	Required
statementId	String		가져올 Statement의 ID	선택
voidedStatementId	String		가져올 취소된 Statement의 ID. Voided Statements 참조.	선택
agent	Agent 또는 식별된 Group (JSON)		Filtering, 지정된 Agent 또는 Group이 Statement의 주체 또는 객체인 경우에만 해당 Statement를 반환한다. LRS가 동일한 역기능 식별자가 각 객체에서 사용되고 해당 역기능 식별자가 동일한 값을 가질 때 Agent 또는 식별된 Group이 동일하다고 간주한다. 이 필터의 목적을 위해 위에서 설명한 역함수 식별자를 기준으로 지정된 에이전트와 일치하는 멤버가 있는 그룹은 일치하는 것으로 간주됩니다. agent/group 개체 정의 참조	선택
verb	Verb ID (IRI)		Filtering, 지정된 Verb ID와 일치하는 Statements만 반환한다.	선택
activity	Activity ID (IRI)		Filtering, Statement의 객체가 지정된 ID를 가진 Activity인 경우에만 해당 Statements를 반환한다.	선택
registration	UUID		Filtering, 지정된 등록 ID와 일치하는 Statements만 반환한다. 일반적으로 고유한 등록이 하나의 Actor에 할당될 것으로 예상되지만 이를 가정해서는 안 된다. 특정 Actor 또는 Activity에 대한 Statements만 필요한 경우 해당 Parameter도 지정해야 한다.	선택
related_activities	Boolean	false	Activity 필터를 널리 적용한다. 객체, Context Activity 중 하나 또는 포함된 SubStatement의 Properties 중 하나와 일치하는 경우 Activity Parameter가 일반적인 동작 대신 사용된다. 일치는 "activity" Parameter와 동일한 방식으로 정의된다.	선택
related_agents	Boolean	false	Agent 필터를 널리 적용한다. Actor, Object, Authority, Instructor, Team 또는 포함된 SubStatement의 Properties 중 하나와 일치하는 경우 Agent Parameter가 일반적인 동작 대신 사용된다. 일치는 "agent" Parameter와 동일한 방식으로 정의된다.	선택
since	Timestamp		지정된 타임스탬프 이후에 저장된 Statements만 반환한다.	선택
until	Timestamp		지정된 타임스탬프와 동일하거나 그 이전에 저장된 Statements만 반환한다.	선택
limit	Nonnegative Integer (음이 아닌 정수)	0	반환할 Statements의 최대 수이다. 0은 서버가 허용하는 최대값을 반환한다는 것을 의미한다.	선택
format	String: (ids, exact,  canonical)	exact	ids인 경우, Agent, Activity, Verb 및 Group 객체를 식별하는 데 필요한 최소 정보만 포함된다.   Exact인 경우, Agent, Activity, Verb 및 Group 객체가 Statement를 수신할 때 정확히 채워진 State로 반환된다. 이용하기 위해 Statement를 가져오는 LRS는 "exact" 형식을 사용하여 Statement의 불변성을 유지하기 위해 사용한다.   canonical의 경우, Activity 객체와 Verb를 정규화된 정의로 반환하며 언어 Filtering 프로세스를 적용한 후 "exact" 모드와 동일한 원래 Agent 및 Group 객체를 반환한다.	선택
attachments	Boolean	false	true인 경우, LRS는 다중 응답 형식을 사용하고 이전에 Description한대로 모든 첨부 파일을 포함한다. false인 경우, LRS는 Content-Type이 application/json인 지정된 응답을 보내고 첨부 파일 데이터를 보내지 않는다.	선택
ascending	Boolean	false	true인 경우, 저장된 시간의 오름차순으로 결과를 반환한다.	선택

참고: Boolean Parameter의 값은 JSON과 같이 true 또는 false로 표시된다.

Requirements

• LRS는 statementId 및 voidedStatementId Parameter가 모두 포함된 이 Resource에 대한 모든 요청을 400 Bad Request 오류로 거부해야 한다.
• LRS는 statementId 또는 voidedStatementId Parameter가 포함되며 "attachments" 또는 "format" 이외의 다른 Parameter도 포함된 이 Resource에 대한 모든 요청을 400 Bad Request 오류로 거부해야 한다.
• LRS는 자격 증명과 관련된 권한에 따라 추가적인 쿼리 필터 기준을 적용할 수 있다.
• 쿼리 필터 기준과 일치하는 Statement가 없는 경우에도 LRS는 여전히 200 OK 및 StatementResult Object를 반환해야 한다. 이 경우 "statements" Properties은 빈 배열을 포함한다.
• LRS는 Statements Resource 요청에 대한 모든 응답에 대해 "X-Experience-API-Consistent-Through" 헤더를 포함해야 한다. 이 헤더의 값은 모든 "stored" Properties이 해당 시간 이전에 사용 가능하다는 합리적인 확신을 가지고 있는 시간을 ISO 8601 결합된 날짜 및 시간 형식으로 나타낸다. 이 시간은 Statements가 검색 가능하게 되는 데 지연을 일으킬 수 있는 과도한 부하와 같은 일시적인 상황을 고려해야 한다. 이것은 최근의 타임스탬프일 것으로 예상되며 최근에 받은 Statements가 없더라도 해당한다.
• GET Statement의 "attachment" Properties이 사용되고 true로 설정된 경우, LRS는 multipart 응답 형식을 사용하고 Part Two에서 Description한대로 모든 첨부 파일을 포함해야 한다.
• GET Statement의 "attachment" Properties이 사용되고 false로 설정된 경우, LRS는 첨부 파일 원본 데이터를 포함해서는 안 되며 application/json으로 보고해야 한다.
• LRS는 "Last-Modified" 헤더를 포함하는 것이 좋다. 이 헤더는 Statement의 "stored" 타임스탬프와 일치해야 한다.

StatementRefs에 대한 필터 조건 (Filter Conditions for StatementRefs)

• 이 섹션은 다른 Statements을 대상으로 하는 Statements에 대한 필터 조건을 Description하며 원래 쿼리의 필터 Parameter와 일치하지 않더라도 쿼리의 필터 조건을 충족하는 경우가 있음을 나타낸다. 이러한 규칙은 "statementId" 또는 "voidedStatementId" 쿼리 Parameter를 사용하여 단일 Statement를 검색할 때는 적용되지 않는다.
• 'Targeting Statements'란 하나의 Statement(Targeting Statement)이 다른 Statement(Targeting Statement)의 Statement ID를 해당 Statement의 객체로 사용하는 Statement 참조를 포함하는 것을 의미한다.
• 시간 또는 순서 기반이 아닌 필터 Parameter에 대한 경우 (즉, "since", "until" 또는 "limit" 이외의 경우), 다른 Statement를 대상으로 하는 Statements(Statement의 객체로 StatementRef를 사용)는 대상 Statement이 필터 조건을 충족하는 경우 필터 조건을 충족한다.
• 이러한 규칙은 재귀적으로 적용되므로 "Statement a"가 a가 c를 대상으로 하며 위에서 Description한 필터 조건이 "Statement c"에 대해 일치하는 경우 "Statement a"가 일치한다.
• 예를 들어 'Ben passed explosives training'라는 Statement와 이에 대한 후속 Statement인 "Andrew confirmed <원래 Statement의 StatementRef>"를 고려해보면 후속 Statement에는 'Ben' 또는 'explosives training'이 언급되지 않지만 'Ben'을 Actor 필터 또는 'explosives training'을 Activity 필터로 사용하여 Statements를 가져오는 경우에는 두 Statements가 일치하고 반환된다. 이는 가져 오려는 시간 또는 순서에 따라 해당된다.

참고: Context 내부의 "Statement" Properties 값으로 사용되는 StatementRefs는 Statements의 Filtering에 영향을 미치지 않는다.

Canoncial 형식 Statements에 대한 언어 Filtering Requirements
(Language Filtering Requirements for Canonical Format Statements)

• Activity Objects에는 "name", "description" 및 다양한 상호 작용 구성 요소 내에서 언어 지도(Language Map) 개체가 포함되어 있다. LRS는 각 언어 지도에서 하나의 언어만 반환해야 한다.
• LRS는 언어 지도를 포함하는 객체를 식별하는 IRI에 대한 정규 버전을 유지할 수 있다. 이는 Verb의 "display" Properties에 저장된 언어 지도 및 확장 내에서 사용되는 일부 언어 지도를 포함한다.
• LRS가 언어 지도의 정규 버전을 유지하는 경우, 정규 형식을 사용하여 Statements를 검색할 때 이 정규 언어 지도를 반환해야 한다.
• LRS는 언어 지도를 반환할 때 반환되는 언어 지도에서 하나의 언어만 반환해야 한다.
• 가장 관련성 있는 언어를 선택하기 위해 LRS는 RFC 2616 (HTTP 1.1)에서 Description한대로 "Accept-Language" 헤더를 적용해야 한다. 다만 이 논리는 각 언어 지도에 개별적으로 적용되어 포함할 언어 항목을 선택할 때 전체 Resource(Statements 목록)에 적용되는 것이 아니라 개별적으로 적용되어야 한다.

2.1.4 취소된 Statements (Voided Statements)

Part Two에서는 Statements를 취소하는 프로세스를 Description한다. 이 섹션에서는 쿼리될 때 취소된 Statements가 LRS에서 처리되는 방법을 Description한다.

클라이언트는 취소된 Statements의 존재와 Statement ID를 취소 Statement의 대상으로 확인할 수 있다. 디버깅 도구를 제외하고는 많은 Learning Record Consumers가 취소 Statement를 사용자에게 표시하고 Activity 스트림 및 기타 보고서의 일부로 표시하지 않으려고 할 것이다.

Requirements

• LRS는 voidedStatementId로 요청되지 않은 한 취소된 Statement를 반환해서는 안 된다. StatementRefs에 대한 필터 조건 섹션에서 Description된 프로세스도 이 Requirements에 예외가 없다. 취소 Statement를 검색하는 프로세스는 voidedStatementId별로 각각 요청하는 것이다.
• LRS는 여전히 취소된 Statement를 대상으로 하는 Statements를 반환해야 한다. StatementRefs에 대한 필터 조건 섹션에서 Description된 프로세스와 조건을 따른다. 이에는 취소 Statement도 포함되며 취소할 수 없다.

2.2 문서 Resource

Description

Experience API는 학습 레코드 제공자가 문서의 형태로 임의의 데이터를 저장할 수 있는 기능을 제공한다. 이 데이터는 Activity, Agent 또는 두 가지의 조합과 관련될 수 있다.

Details

다음 표는 많은 다른 표와 달리 JSON 개체가 아닌 일반 Properties을 보여줍니다. "id"는 IRL에 저장되고, "updated"는 HTTP 헤더 정보이며, "contents"는 HTTP 문서 자체를 나타낸다 (개체가 아님).

Properties	Type	Description
id	String	학습 레코드 제공자에 의해 설정되며 Agent 또는 Activity의 범위 내에서 고유한
updated	Timestamp	문서가 가장 최근에 수정된 시간
contents	임의의 이진 데이터	문서의 내용

세 가지 문서 Resource는 문서 저장을 제공한다. 각 Resource의 Details는 다음 섹션에서 찾을 수 있으며 이 섹션의 정보는 세 Resource에 모두 적용된다.

Details

Resource 이름	메서드	엔드포인트	예제
State Resource	POST	activities/state	http://example.com/xAPI/activities/state
Activity Profile Resource	POST	activities/profile	http://example.com/xAPI/activities/profile
Agent Profile Resource	POST	agents/profile	http://example.com/xAPI/agents/profile

Requirements

·       학습 레코드 제공자는 LRS가 사전에 알지 못하는 Activity 및 Agent에 대한 문서를 Document Resource 중 하나로 보낼 수 있다.

·       LRS는 Activity 및/또는 Agent에 대한 사전 지식이 없어도 문서를 거부해서는 안 된다.

“Last Modified"

"Last Modified" 헤더는 단일 또는 여러 문서를 GET 요청에 대한 응답으로 반환할 때 LRS에 의해 설정된다.

Requirements

• 단일 문서를 반환할 때 LRS는 문서가 마지막으로 수정된 시간을 나타내는 "Last-Modified" 헤더를 포함해야 한다.
• 여러 문서를 반환할 때 LRS는 가장 최근에 수정된 문서의 마지막 수정 시간을 나타내는 "Last-Modified" 헤더를 포함해야 한다.

Requirements 있는 JSON Procedure (JSON Procedure with Requirements)

학습 레코드 제공자가 JSON 객체로 변수를 문서에 저장하고 콘텐츠 Type이 application/json인 경우, POST를 사용하여 변수 집합으로 조작할 수 있다.

다음 프로세스는 해당 프로세스와 프로세스 Requirements을 Description한다. 예를 들어, 문서에는 다음과 같이 포함되어 있다.

{              "x" : "foo",              "y" : "bar" }

LRS가 콘텐츠 Type이 application/json인 기존 문서에 대한 POST 요청을 받으면, LRS는 POST된 문서를 기존 문서와 병합해야 한다. 이 문맥에서 병합은 다음과 같이 정의된다.

• 각 문서를 나타내는 개체로 직렬화한다.
• POST된 문서에서 직접 정의된 각 Properties에 대해 기존 개체의 해당 Properties을 POST된 개체의 값으로 설정한다.
• 요청에서 참조된 문서로 기존 개체의 유효한 JSON 직렬화를 저장한다.

최상위 properties 가 Object인 경우에도 최상위 properties 만 병합된다는 점에 유의한다. 각 원래 properties 의 전체 내용이 각 새 properties 의 전체 내용으로 대체된다.

예를 들어, 기존 문서와 동일한 ID로 다음 문서가 POST됐다.

{              "x" : "bash",              "z" : "faz" }

LRS에 저장된 결과 문서는 다음과 같다.

{              "x" : "bash",              "y" : "bar",              "z" : "faz" }

Requirements

• 게시되는 문서 또는 기존 문서 중 하나라도 Content-Type이 application/json이 아니거나 두 문서 중 하나라도 JSON 객체로 구문 분석할 수 없는 경우, LRS는 HTTP State 코드 400 Bad Request로 응답하고 요청의 결과로 대상 문서를 업데이트해서는 안 된다.
• 병합이 성공하면 LRS는 HTTP State 코드 204 No Content로 응답해야 한다.
• 학습 레코드 제공자가 Properties을 삭제해야 하는 경우, 아래에 Description된 대로 전체 문서를 대체하기 위해 PUT 요청을 사용해야 한다.

2.3 State Resource

Description

일반적으로 이 Resource는 자체 내부 저장소가 없거나 장치 간에 State를 유지해야 하는 학습 레코드 제공자를 위한 scratch 영역이다.

Details

호출의 의미는 "stateId" Parameter에 의해 결정된다. "stateId"가 포함되면 GET 및 DELETE 메서드가 "stateId"로 식별된 단일 정의된 State 문서에 작용한다. 그렇지 않으면 GET은 사용 가능한 ID를 반환하고 DELETE는 다른 Parameter를 통해 지정된 Context에서 모든 State를 삭제한다. 이 Resource에는 동시성 제어가 연결되어 있다.

단일 문서 (PUT | POST | GET | DELETE)

예제 엔드포인트: http://example.com/xAPI/activities/state

지정된 "stateId"에 따라 지정된 Activity, Agent 및 등록(지정된 경우)의 Context 내에 존재하는 문서를 저장, 변경, 가져오거나 삭제한다.

콘텐츠 (PUT | POST): 저장하거나 업데이트할 문서이다.

콘텐츠 (GET | DELETE): None

반환 (PUT | POST | DELETE): 204 No Content

반환 (GET): 200 OK, the State document

Parameter	Type	Description	Required
activityId	Activity id (IRI)	이 State와 관련된 Activity ID이다.	필수
agent	Agent Object (JSON)	이 State와 관련된 Agent이다.	필수
registration	UUID	이 State와 관련된 등록이다. (선택)
stateId	String	지정된 Context 내에서 이 State의 ID이다.	필수

복합 문서 GET (Multiple Document GET)

예제 엔드포인트: http://example.com/xAPI/activities/state

이 Context (Activity + Agent [등록이 지정된 경우])의 모든 State 데이터의 State ID를 검색한다. "since" Parameter가 지정된 경우, 이것은 지정된 타임스탬프 (배제) 이후에 저장되거나 업데이트된 항목으로 제한된다.

콘텐츠: None

반환: 200 OK,  Array of State id(s)

Parameter	Type	Description	필수
activityId	Activity id (IRI)	이 State와 관련된 Activity ID이다.	필수
agent	Agent object (JSON)	이 State와 관련된 Agent이다.	필수
registration	UUID	이 State와 관련된 등록이다. (선택)
since	Timestamp	지정된 타임스탬프 (배제) 이후에 저장된 State의 ID만 반환된다.	선택

복합 문서 DELETE (Multiple Documentation DELTE)

예제 엔드포인트: http://example.com/xAPI/activities/state

이 Context (Activity + Agent [+ 등록이 지정된 경우])의 모든 State 데이터를 삭제한다.

콘텐츠: None

반환: 204 No Content

Parameter	Type	Description	Required
activityId	Activity id (IRI)	이 State와 관련된 Activity ID이다.	필수
agent	Agent object (JSON)	이 State와 관련된 Agent이다.	필수
registration	UUID	이 State와 관련된 등록이다. (선택)

2.4 Agent Resource

Agent Resource는 외부 서비스(디렉토리 서비스 등)에서 파생된 Agent에 대한 정보를 검색하기 위한 방법을 제공한다. 이 Resource에는 동시성 제어가 연결되어 있다.

결합된 정보 GET (Combined Information GET)

Details

예제 엔드포인트: http://example.com/xAPI/agents

특정 Agent에 대한 특별한 Person Object를 반환한다. Person Object는 Agent Object와 매우 유사하지만 각 Properties이 단일 값을 가지는 대신 각 Properties이 배열 값을 가지며 여러 식별 Properties을 포함하는 것이 가능한다. 이것은 FOAF(person-centric) 개념과 다릅니다. 여기서 person은 LRS Agent 데이터의 person 중심 뷰를 나타내기 위해 사용되었지만 Agent는 하나의 persona(특정 맥락에서의 개인)를 참조한다.

“agent” Parameter는 단일 식별자 및 배열이 없는 일반 Agent Object이다. 이것은 Person Object나 Group이 아니다.

콘텐츠: None

반환: 200 OK, Person Object

Parameter	Type	Description	Required
agent	Agent object (JSON)	확장된 Agent 정보를 가져오기 위해 사용할 Agent 표현.	필수

Requirements

• Person Object의 여러 식별 Properties을 반환할 수 있는 LRS는 연결 자격 증명에 증가된 명시적 권한을 요구해야 한다.
• 불충분한 권한이 있는 요청은 403 Forbidden으로 거부해야 한다.
• LRS가 Agent에 대한 추가 정보를 반환할 수 없는 경우, 쿼리될 때 LRS는 여전히 요청된 Agent와 관련된 정보만 포함하는 Person Object를 반환해야 하지만 해당 Person Object에는 요청된 Agent와 관련된 정보만 포함된다.

참고: 이것은 LRS가 사전에 알지 못하는 Agent에 대한 요청이 있더라도 요청에서 받은 Agent 정보를 포함하는 Person 객체를 반환한다는 것을 의미한다.

Person Properties

Details

Properties	Type	Description	Required
objectType	String	Person	필수
name	Array of strings	검색한 Agent의 이름 목록.	선택
mbox	Array of IRIs in the form "mailto:email address"	검색한 Agent의 이메일 주소 목록.	선택
mbox_sha1sum	Array of strings	mailto IRI(mbox Properties의 go와 같은)의 SHA1 해시 목록.	선택
openid*	Array of strings	Agent를 고유하게 식별하는 openids 목록.	선택
account*	Array of account objects	일치하는 계정 목록. 완전한 계정 객체(homePage와 name)를 제공해야 한다.	선택

Requirements

• 모든 배열 Properties은 Agent Objects의 동일한 정의를 가진 멤버로 채워져야 한다.
• 여기에 나열되지 않은 추가 Properties은 추가해서는 안 되며 각 Properties은 한 번만 발생해야 한다.

2.5 Activities Resource (Activities Resource)

Activities Resource는 LRS(Learning Record Store)에서 Activity의 전체 Description을 검색하기 위한 방법을 제공한다. 이 Resource에는 동시성 제어가 연결되어 있다.

전체 활동 객체 GET (Full Activity Object GET)

예제 엔드포인트: http://example.com/xAPI/activities

지정된 완전한 Activity 객체를 로드한다.

콘텐츠: None

반환: 200 OK, Content

Parameter	Type	Description	필수
activityId	Activity id (IRI)	로드할 Activity과 관련된 ID.	필수

Requirements

• LRS가 반환할 Activity의 정식 정의가 없는 경우에도 LRS는 쿼리될 때 여전히 Activity 객체를 반환해야 한다.

2.6 Agent Profile Resource

Description

Agent Profile Resource는 State Resource와 유사하며, Agent와 관련된 임의의 키/문서 쌍을 저장할 수 있는 기능을 제공한다.

Details

요청의 의미는 "profileId" Parameter에 의해 결정된다. 이 Parameter가 포함된 경우 GET 메서드는 "profileId"로 식별된 단일 정의 문서에 작용한다. 그렇지 않으면 GET은 사용 가능한 ID를 반환한다.

단일 Agent 또는 Profile 문서 (PUT | POST | GET | DELETE)

예제 엔드포인트: http://example.com/xAPI/agents/profile

지정된 Agent의 맥락에서 지정된 Profile document를 저장, 변경, 가져오거나 삭제한다.

콘텐츠 (PUT | POST): 저장하거나 업데이트할 document이다.

콘텐츠 (GET | DELETE): None

반환 (PUT | POST | DELETE): 204 No Content

반환 (GET): 200 OK, Profile document

Parameter	Type	Description	필수
agent	Agent object (JSON)	이 Profile 문서와 관련된 Agent.	필수
profileId	String	이 Profile 문서와 관련된 Profile ID.	필수

참고: "agent" Parameter는 Agent 개체이며 Group이 아니다. 데이터를 식별된 Group에 대한 정보를 저장하려는 학습 레코드 제공자는 Agent Object 내에서 식별된 Group의 식별자를 사용할 수 있다.

다중 문서 GET (Multiple Document GET)

예제 엔드포인트: http://example.com/xAPI/agents/profile

Agent의 모든 Profile 문서에 대한 Profile ID를 가져온다. "since" Parameter가 지정된 경우 이는 지정된 타임스탬프 이후에 저장되거나 업데이트된 항목으로 제한된다.

콘텐츠: None

반환: 200 OK, Array of Profile ID

Parameter	Type	Description	Required
agent	Agent object (JSON)	이 Profile 문서와 관련된 Agent.	필수
since	Timestamp	지정된 타임스탬프 이후에 저장된 Profile ID만 반환된다. (배타적)	선택

2.7 Activity Profile Resource

Description

Activity Profile Resource는 State Resource와 유사하며, Activity과 관련된 임의의 키/문서 쌍을 저장할 수 있는 기능을 제공한다.

Details

요청의 의미는 "profileId" Parameter에 의해 결정된다. 이 Parameter가 포함된 경우 GET 메서드는 "profileId"로 식별된 단일 정의 문서에 작용한다. 그렇지 않으면 GET은 사용 가능한 ID를 반환한다.

단일 문서 (PUT | POST | GET | DELETE)

예제 엔드포인트: http://example.com/xAPI/activities/profile

지정된 Activity의 맥락에서 지정된 Profile 문서를 저장, 변경, 가져오거나 삭제한다.

콘텐츠 (PUT | POST): 저장하거나 업데이트할 문서이다.

콘텐츠 (GET | DELETE): None

반환 (PUT | POST | DELETE): 204 No Content

반환 (GET): 200 OK, Profile Document

Parameter	Type	Description	Required
activityId	Activity id (IRI)	이 Profile 문서와 관련된 Activity ID.	필수
profileId	String	이 Profile 문서와 관련된 Profile ID.	필수

다중 문서 GET (Multiple Document GET)

예제 엔드포인트: http://example.com/xAPI/activities/profile

Activity에 대한 모든 Profile 문서의 Profile ID를 가져온다. "since" Parameter가 지정된 경우 이는 지정된 타임스탬프 이후에 저장되거나 업데이트된 항목으로 제한된다.

콘텐츠: None

반환: 200 OK, Array of Profile ID

Parameter	Type	Description	Required
activityId	Activity id (IRI)	이 Profile 문서와 관련된 Activity ID.	필수
since	Timestamp	지정된 타임스탬프 이후에 저장된 Profile 문서의 ID만 반환된다. (배타적)	선택

2.8 About Resource

Description

xAPI 버전 지원을 포함한 이 LRS에 관한 정보를 포함하는 JSON 객체를 반환한다.

Rationale

주로 이 Resource는 여러 xAPI 버전을 지원하는 클라이언트가 LRS와 통신할 때 사용할 버전을 결정할 수 있도록 한다. 다른 용도가 나타날 수 있도록 확장이 포함되어 있다.

Details

정보 GET (Information GET)

예제 엔드포인트: http://example.com/xAPI/about

콘텐츠: None

반환: 200 OK, 이 LRS에 관한 기본 메타데이터를 포함하는 JSON 객체

Properties	Type	Description	Required
version	Array of version strings	이 LRS가 지원하는 xAPI 버전	필수
extensions	Object	다른 필요한 Properties의 맵	선택

Requirements

• LRS는 각 주요 버전에 대해 LRS가 준수하는 최신 마이너 및 패치 버전을 포함하는 "version" Properties이 포함된 위에서 Description한 JSON 문서를 반환해야 한다.
• 확장 외에 이 객체에 추가 Properties을 추가해서는 안 되며, 각 Properties은 확장을 제외하고 한 번만 발생해야 한다.
• LRS는 이 Resource에 대한 인증되지 않은 액세스를 허용해야 한다.
• 버전 관리에서 요구되는 것처럼 버전 헤더를 기반으로 요청을 거부해서는 안 된다.

3.0 데이터 유효성 검사
Data Validation

---

Description

xAPI 내의 LRS(Learning Record Store)의 역할은 Statements을 저장하고 검색하는 것이다. 충분한 정보가 있으면 이러한 작업을 수행할 것으로 예상된다. Experience API의 문장 유효성 검사는 구문(syntax)에만 중점을 두며 의미(semantics)에 관한 규칙을 강제하지 않는다. Verb 정의(Verb definitions), 활동 유형(Activity types), 그리고 확장(extension)에 대한 의미의 유효성을 보장하기 위한 규칙은 문장을 보내는 학습 기록 제공자(Learning Record Provider)의 책임이다.

Requirements

LRS는 구조에 관한 규칙을 강제해야 한다. LRS는 의미에 관한 규칙을 강제해서는 안 된다.

3.1 동시성 (Concurrency)

Description

동시성 제어는 클라이언트가 예전 데이터를 기반으로 문서를 PUT, POST 또는 DELETE하지 않도록 하는 것이다.

Details

xAPI는 PUT, POST 또는 DELETE가 기존 데이터를 덮어쓰거나 제거할 수 있는 API 부분에서 낙관적 동시성 제어를 구현하기 위해 HTTP 1.1 엔터티 태그(ETags)를 사용한다. 이러한 API 부분은 다음과 같다:

• State Resource
• Agent Profile Resource
• Activity Profile Resource

Client Requirements

State Resource는 동시성 헤더 없이 PUT, POST 및 DELETE 요청을 허용할 것이므로 아래 Requirements은 Agent Profile Resource와 Activity Profile Resource에만 적용된다.

• Agent Profile Resource 또는 Activity Profile Resource에 PUT 요청을 보내는 클라이언트는 "If-Match" 헤더 또는 “If-None-Match” 헤더를 포함해야 한다.
• Agent Profile Resource 또는 Activity Profile Resource에 POST 요청을 보내는 클라이언트는 "If-Match" 헤더 또는 “If-None-Match” 헤더를 포함해야 한다.
• Agent Profile Resource 또는 Activity Profile Resource에 DELETE 요청을 보내는 클라이언트는 "If-Match" 헤더를 포함해야 한다.
• 클라이언트는 LRS가 제공하는 ETag 값을 직접 계산하는 대신 사용해야 한다.

LRS Requirements

• GET 요청에 응답하는 LRS는 응답에 ETag HTTP 헤더를 반드시 추가해야 한다.
• 전송 인코딩을 사용하지 않거나 identity 전송 인코딩을 사용하지 않고 GET 요청에 응답하는 LRS는 ETag 헤더의 값을 내용의 SHA-1 다이제스트(hexadecimal string)로 계산해야 한다. 이 16진수 문자열은 숫자와 소문자 문자만 사용하여 렌더링해야 한다. 대문자 문자를 사용해서는 안 된다. 이러한 방식으로 ETag를 계산하는 Requirements은 향후 명세의 버전에서 제거될 예정이다.
• GET 요청에 응답하는 LRS는 기존 웹 인프라에서 ETag의 해석에 따라, 상기와 같은 방식으로 ETag를 계산해서는 안 된다.
• RFC 2616에서 정의한 대로 GET 요청에 응답하는 LRS는 헤더를 따옴표로 묶어야 한다.
• PUT 요청에 응답하는 LRS는 "If-Match" 헤더를 다루어야 하며, ETag를 포함하고 있으면 RFC2616, HTTP 1.1에 Description된 대로 문서를 마지막으로 가져온 이후에 수정 사항을 감지하기 위해 처리해야 한다.
• PUT 요청에 응답하는 LRS는 "If-None-Match" 헤더를 다루어야 하며, "*"를 포함하고 있으면 RFC2616, HTTP 1.1에 Description된 대로 클라이언트가 인식하지 못하는 Resource가 존재하는지 감지하기 위해 처리해야 한다.
•  POST 또는 DELETE 요청에 응답하는 LRS는 "If-Match" 헤더를 처리해야 한다. 이 헤더에 ETag가 포함되어 있다면, 문서를 마지막으로 가져온 후에 수정된 내용을 감지하기 위해 RFC2616, HTTP 1.1에 설명된대로 처리해야 한다.
•  POST 요청에 응답하는 LRS는 "If-None-Match" 헤더를 처리해야 한다. 이 헤더에 "*"이 포함되어 있다면, 클라이언트가 인식하지 않는 리소스가 존재하는지 감지하기 위해 RFC2616, HTTP 1.1에 설명된대로 처리해야 한다.

위에서 Description한 PUT 요청 사례 중 어느 하나의 헤더 선행 조건(precondition)이 실패하는 경우 LRS는 다음과 같아야 한다:

• HTTP State 412 Precondition Failed를 반환해야 한다.
• Resource를 수정해서는 안 된다.

위에서 Description한 POST 또는 DELETE 요청 사례 중 어느 하나의 헤더 선행 조건(precondition)이 실패하는 경우 LRS는 다음과 같아야 한다:

• HTTP State 412 Precondition Failed를 반환하는 것을 권장한다.
• Resource를 수정해서는 안 된다.

기존에 이미 존재하는 Resource에 대한 PUT 요청이 헤더 없이 수신된 경우 LRS는 다음과 같아야 한다:

• HTTP State 409 Conflict를 반환해야 한다.
• 현재 Resource State를 확인하라는 응답을 반환해야 한다.
• Resource를 수정해서는 안 된다.

3.2 오류 코드 (Error Codes)

이 명세서는 LRS(Learning Record Store)에 대해 특정 조건에서 요청을 수락 또는 거부하고 응답을 반환하며 다른 동작을 수행하기 위해 요구되는 일부 Requirements을 정의한다. LRS가 요청을 거부해야 하는 경우, 해당 Requirements의 일부로 적절한 오류 코드가 나열된다.

이러한 Requirements 중 어떤 것도 LRS가 설정에 따라 요청을 거부하고 다른 조건에 따라 응답하거나 다르게 동작하는 것과 모순되지 않는다. 이 명세서의 범위를 벗어나는 조건을 기반으로 요청을 거부하고 응답하거나 다르게 동작할 수 있는 구성 가능성도 허용된다.

하나의 이러한 조건은 권한이다. 예를 들어, LRS는 특정 자격 증명 집합에 권한을 할당할 수 있으며, 해당 자격 증명을 사용하여 특정 Agent와 관련된 문장만 발행할 수 있도록 할 수 있다. 그런 다음 그 자격 증명을 사용하여 해당 Agent와 관련이 없는 문장을 거부할 수 있다. LRS가 할당할 수 있는 권한은 이 명세서의 범위를 벗어나며, 섹션 4.2의 권장 OAuth 승인 범위 값 목록을 제외하고는 명세서의 범위를 벗어난다.

권한은 또한 GET 요청에 대한 LRS의 반환 응답에 영향을 미칠 수 있다. 예를 들어, 일련의 자격 증명은 특정 Actor에 대한 문장만 보는 권한을 가질 수 있으며, 이 경우 LRS는 해당 Actor와 관련이 없는 문장을 제외하도록 반환된 문장을 Filtering한다. 자세한 내용은 GET Statements를 참조하시오.

이 명세서에 명시적으로 허용된 경우 요청을 처리하는 데 사용되는 자격 증명도 LRS 동작에 영향을 줄 수 있다. 예를 들어, LRS는 일반적으로 문장의 "authority" Properties을 덮어쓴다. 그러나 사용된 자격 증명과 강력한 신뢰 관계가 있는 경우 제출된 권한을 허용할 수도 있다. 자세한 내용은 Authority를 참조하시오.

LRS에 의해 설정된 권한은 기술적으로 준수하는 LRS를 준수 실험에서 실패시킬 수 있다. 이것은 실험용 소프트웨어에 의해 만들어진 요청이 권한을 기반으로 거부될 때 발생할 수 있다. 이러한 이유로 LRS는 구성 가능해야 하거나 실험용으로 사용되는 자격 증명은 권한을 충분히 부여받아 권한 제한이 준수 실험의 결과에 영향을 미치지 않도록해야 한다.

다른 조건은 LRS에서 설정한 크기 제한을 초과하는 요청일 때 발생한다. LRS가 항상 모든 크기의 요청을 수락할 것을 기대하는 것은 합리적이지 않는다. LRS는 자체적으로 적합한 크기 제한을 선택할 수 있지만, 준수 실험 중에 크기 제한을 적용하지 않도록 구성 가능해야 한다. 물론 하드웨어의 제한으로 인해 일부 크기 제한이 여전히 준수 실험 중에 존재할 수 있지만 이러한 제한은 실험의 실행에 영향을 미치지 않을 정도로 충분히 높을 것으로 예상된다.

LRS는 의심스러운 악의적인 의도로 인해 요청을 거부하거나 자격 증명을 취소할 수도 있다. 예를 들어, 짧은 시간 내에 예상치 못하게 많은 요청이 수신된 경우이다. LRS는 준수 실험 중에 요청이 일정 기간 동안 클라이언트나 자격 증명 집합으로부터 너무 많은 요청을 받아들이지 않을 것으로 예상된다.

Details

내용 아래 목록은 API의 다양한 메소드에서 반환될 수 있는 HTTP 오류 코드에 대한 일반적인 지침을 제공한다.

• 400 Bad Request - 잘못된 또는 누락된 인수로 인한 오류 상황을 나타낸다. "잘못된 인수"라는 용어에는 형식이 잘못된 JSON 또는 잘못된 객체 구조가 포함된다.
• 401 Unauthorized - 인증이 필요하거나 요청에 인증이 제출되었지만 제공된 자격 증명이 거부되었음을 나타낸다.
• 403 Forbidden - 해당 자격 증명에 대한 요청이 허가되지 않음을 나타낸다. 이 경우 제공된 자격 증명이 거부된 것과 다릅니다. 이 경우 자격 증명은 유효성이 검사되었지만 인증된 클라이언트가 주어진 작업을 수행할 수 없다.
• 404 Not Found - 요청한 Resource를 찾을 수 없음을 나타낸다. 특정 문서를 대상으로 하는 State, Agent Profile 또는 Activity Profile Resource 요청 또는 단일 문장을 검색하는 메소드와 같이 고유하게 식별되는 Resource를 반환하는 모든 메소드에 의해 반환될 수 있다.
• 409 Conflict - Resource의 현재 State와 충돌로 인한 오류 상황을 나타낸다. State Resource, Agent Profile Resource 또는 Activity Profile Resource 요청 또는 Statement Resource의 PUT 또는 POST 호출의 경우에 해당한다. 자세한 내용은 Section 3.1 Concurrency를 참조하시오.
• 412 Precondition Failed - 요청과 함께 게시된 사전 조건의 실패로 인한 오류 상황을 나타낸다. State 또는 Agent Profile 또는 Activity Profile API 요청의 경우 해당한다. 자세한 내용은 Section 6.3 Concurrency를 참조하시오.
• 413 Request Entity Too Large - 문장 또는 요청에 포함된 첨부 파일의 크기가 LRS에서 허용하는 최대 크기보다 크기 때문에 문장 또는 문서가 거부되었음을 나타낸다.
• 429 Too Many Requests - LRS가 클라이언트나 자격 증명 집합으로부터 주어진 시간 동안 너무 많은 요청을 받아들였기 때문에 요청이 거부되었음을 나타낸다.
• 500 Internal Server Error - 일반적인 오류 상황을 나타낸다. 일반적으로 서버에서 처리 중 예상치 못한 예외를 나타낸다.

Requirements

• LRS는 위에 나열된 오류 조건 중에서 가장 적합한 오류 코드를 반환해야 한다.
• LRS는 응답에 오류의 원인을 Description하는 메시지를 반환하는 것이 좋다.
• LRS는 오류의 형식을 결정하기 위해 RFC 7231에서 Description한 내용과 같이 콘텐츠 협상을 사용해야 한다.
• LRS는 오류에 대한 플레인 텍스트, HTML 및 JSON 응답을 허용해야 한다 (콘텐츠 협상을 사용하여).
• 학습 레코드 제공자는 콘텐츠 협상을 활성화하기 위해 요청에 "Accept" 헤더를 보내야 한다.
• LRS는 콘텐츠 Type 헤더가 요청에 포함된 콘텐츠와 일치하지 않거나 요청의 구조가 특정 콘텐츠 Type에 대한 이 명세서에 Description된 구조와 일치하지 않는 경우 400 Bad Request State로 요청을 거부해야 한다. 예를 들어, 요청의 콘텐츠가 JSON 형식으로 포맷되어 있다면, 콘텐츠 Type이 application/json으로 예상된다. application/x-www-form-urlencoded로 콘텐츠 Type이 설정되면, 요청은 Alternate Request Syntax에 Description된대로 method 매개 변수를 포함해야 한다.
• LRS는 이 명세서에서 의도된 Context에서 인식하지 않는 모든 매개 변수를 사용하는 요청을 400 Bad Request State로 거부해야 한다. (참고: LRS는 이 명세서에 없는 매개 변수를 인식하고 처리할 수 있다).
• LRS는 이 명세서에서 Description한 매개 변수와 일치하는 매개 변수를 사용하는 요청을 400 Bad Request State로 거부해야 한다.
• LRS는 한 배치 내에서 거부된 문장이 있으면 해당 배치를 거부해야 한다.
• LRS는 요청과 관련된 자격 증명이 해당 요청을 수행할 권한이 없는 경우 403 Forbidden State로 요청을 거부해야 한다.
• LRS는 첨부 파일, 문장 또는 문서의 크기가 LRS에서 허용하는 최대 크기보다 큰 경우 413 Request Entity Too Large State로 요청을 거부해야 한다.
• LRS는 첨부 파일, 문장 및 문서 크기 제한을 선택할 수 있으며 권한별로 이러한 제한을 변경할 수 있다.
• LRS는 특정 클라이언트 또는 자격 증명 집합에서 일정 기간 동안 너무 많은 요청을 수신하여 요청이 거부된 경우 429 Too Many Requests State로 요청을 거부해야 한다.
• LRS는 권한에 기반하여 첨부 파일, 문장 및 문서 크기 제한을 선택할 수 있으며 권한별로 이러한 제한을 변경할 수 있다.

LRS에 의해 구현된 어떤 제한사항이나 허가사항이 적합성 시험 소프트웨어의 실행에 영향을 미치지 않는지 확인하기 위한 적합성 시험 목적으로 다음과 같은 요구사항이 존재한다.

• LRS가 권한에 기반하여 특정 자격 증명 집합을 사용하여 권한에 따라 요청을 거부하지 않도록 구성 가능해야 한다. 이러한 자격 증명 집합은 준수 테스트에 사용해야 하지만 라이브 시스템에서는 삭제 또는 비활성화될 수 있다.
• LRS는 첨부 파일, 문장 또는 문서를 어떤 합리적인 크기로든 허용하도록 구성 가능해야 한다.
• LRS는 어떤 합리적인 속도로든 요청을 허용하도록 구성 가능해야 한다.

3.3 버전 관리

Rationale

명세서의 미래 개정판에서는 문장에 추가된 Properties과 같은 변경 사항이 도입될 수 있다. Semantic Versioning을 사용하면 명세서가 변경될 때에도 클라이언트와 LRS가 상호 운용성을 유지할 수 있다.

Details

1.0.0 버전부터 xAPI는 Semantic Versioning 1.0.0에 따라 버전이 지정될 것이다. 클라이언트로부터의 모든 요청 및 LRS로부터의 모든 응답은 이름이 X-Experience-API-Version이고 값이 버전인 HTTP 헤더를 포함한다. 예를 들어, 버전 1.0.3의 경우 X-Experience-API-Version : 1.0.3와 같이 표시된다; 현재 명세서 버전에 대한 Revision History를 참조하시오.

참고: 명세서 1.0.0 이후의 패치 버전에 대해서는 "X-Experience-API-Version" 헤더는 항상 1.0.0인 문장 버전 Properties과 일치하지 않는다. "X-Experience-API-Version" 헤더는 LRS와 클라이언트가 따르는 명세서의 정확한 패치 버전을 결정할 수 있게 한다. 1.0.x 버전 간에 통신 불일치가 발생하지 않아야 하지만 이전에 의도한 동작에 대한 명확화가 때로는 필요할 수 있다.

LRS Requirements

• LRS는 모든 응답에 "X-Experience-API-Version" 헤더를 포함해야 한다.
• LRS는 이 헤더를 최신 패치 버전으로 설정해야 한다.
• LRS는 버전 헤더가 1.0인 요청을 1.0.0 버전 헤더로 처리해야 한다.
• LRS는 헤더 버전이 1.0.0 이전인 요청을 거부해야 한다. 단, 해당 요청이 헤더에 지정된 이전 버전의 완전 준수 구현으로 라우팅되는 경우는 제외한다.
• LRS는 버전 헤더가 없는 요청을 거부해야 한다. 단, 해당 요청이 완전한 준수 0.9 구현으로 라우팅되는 경우는 제외한다.
• LRS는 요청이 그 외에 유효한 경우 버전 헤더가 1.0으로 시작하는 요청을 수락해야 한다.
• LRS는 버전 헤더가 1.1.0 또는 그 이상인 요청을 거부해야 한다.
• LRS는 이러한 거부를 문제에 대한 간단한 Description을 포함하는 400 Bad Request 오류로 응답함으로써 수행해야 한다.

Client Requirements

• 클라이언트는 모든 요청에 "X-Experience-API-Version" 헤더를 포함해야 한다.
• 클라이언트는 이 헤더를 최신 패치 버전으로 설정해야 한다.
• 클라이언트는 버전 1.0.0 이상인 응답을 수용해야 한다.
• 클라이언트는 추가 Properties을 가진 데이터 구조를 수용해야 한다.
• 클라이언트는 명세서 1.0.0 버전에서 정의되지 않은 Properties을 무시해야 한다.

Conversion Requirements

• 새로운 버전의 문장은 이전 버전 형식으로 변환해서는 안 된다. 즉, 버전 간의 차이를 처리하기 위해 이전 버전 형식으로 변환해서는 안 된다.
• 이전 버전의 문장은 Appendix A: Converting Statements to 1.0.0에 Description된 방법을 따라 새로운 버전으로만 변환할 수 있다.

4.0 인증
Authentication

---

Rationale

상호 운용성과 다양한 환경에서의 보안 Requirements을 균형잡기 위해 여러 가지 인증 선택이 정의된다.

Details

다음은 명세서 내에서 정의된 인증 방법이다. 특정 LRS는 이러한 방법 중 적어도 하나를 구현하고 이 명세서 내에서 정의되지 않은 추가적인 방법을 구현할 수 있다.

• OAuth 1.0 (RFC 5849) - "HMAC-SHA1", "RSA-SHA1", "PLAINTEXT"와 같은 서명 방법 사용
• HTTP 기본 인증 (HTTP Basic Authentication)
• 공통 액세스 카드 (Common Access Cards)

Common Access Cards는 이 명세서 내에서 인증 방법으로 정의되어 있지만, 이 인증 방법의 구현 Details는 정의되어 있지 않는다. xAPI Working Group은 Common Access Cards를 인증 방법으로 구현하는 LRS 개발자들이 이 인증 방법의 Details를 정의하기 위해 협력하도록 권장하며, 이를 향후 명세서 버전에서 정의할 것을 권장한다.

HTTP 기본 인증은 RFC 7235에서 명확하고 완전하게 정의되어 있으므로 이 명세서에서 추가 정보를 제공하지 않는다.

Requirements

• LRS는 이 명세서에서 정의된 적어도 하나의 인증 방법을 사용하여 인증을 지원해야 한다.
• LRS는 문장의 유효성을 결정하거나 위임하고, 사용된 자격 증명에 기반하여 수행할 수 있는 작업을 결정해야 한다.

4.1 OAuth 1.0 인증 시나리오와 방법 (Oauth 1.0 Authentication Scenarios and Methods)

다음 매트릭스와 Requirements은 OAuth 내에서 사용되는 가능한 인증 시나리오를 Description하고 이러한 시나리오에서 사용할 인증 워크플로우를 권장한다. 각 시나리오에 대한 Description은 포괄적일 목적이 아니며 표준 OAuth 워크플로우의 변형을 개요화한 것이다.

이 섹션의 Requirements은 LRS가 OAuth 1.0을 지원하는 경우에만 적용된다.

• 등록된 애플리케이션(registered application)은 LRS에 등록된 OAuth 소비자로 LRS에 등록된 애플리케이션을 인증하는 애플리케이션이다.
• 알려진 사용자(known user)는 LRS의 사용자 계정이거나 LRS가 사용자를 정의하는 데 신뢰하는 시스템에 있는 사용자이다.

	Known user	User unknown
Application is registered	OAuth의 표준 워크플로우를 사용한다.	LRS는 애플리케이션이 사용자 자격 증명을 추가로 요구하지 않고 xAPI에 액세스할 수 있다고 신뢰한다. OAuth 토큰 단계가 호출되지 않는다.
Application is not registered	애플리케이션 Agent는 등록된 Agent로 식별되지 않으며 LRS는 그 정체성에 대한 가정을 할 수 없다.
No application	애플리케이션이 관련되지 않은 경우에 OAuth 대신 HTTP 기본 인증이 사용된다.
No authentication	LRS에서 지원될 수 있으며 테스트 목적으로 지원될 수 있다.

Requirements

• LRS는 애플리케이션의 이름과 고유한 소비자 키(식별자)를 기록해야 한다.
• LRS는 이 등록을 완료하기 위한 메커니즘을 제공하거나 이러한 메커니즘을 제공하는 다른 시스템으로 위임해야 한다.
• LRS는 다음 중 하나 이상의 방법으로 xAPI의 완전한 지원을 구성할 수 있어야 한다.
• 아래의 워크플로우 시나리오 중 하나 이상의 방법으로.
• LRS는 (보안상의 이유로) 다음을 할 수 있다.
• 아래의 방법 중 일부를 지원한다.
• 알려진 사용자 또는 등록된 애플리케이션을 제한한다.
• LRS는 최소한 "HMAC-SHA1" 및 "RSA-SHA1" 서명을 사용한 OAuth를 지원해야 한다.

등록된 애플리케이션 + 알려진 사용자 프로세스와 Requirements
(Application Registered + Known user Process and Requirements)

Process: OAuth 1.0의 표준 워크플로우를 사용한다.

Requirements

• LRS는 OAuth 권한 범위의 Resource를 지원하여 표준 OAuth 워크플로우를 완료해야 한다 (이 명세서에는 자세한 내용이 없음).
• 이 형태의 인증이 문장을 기록하는 데 사용되고 권한이 지정되지 않은 경우, LRS는 권한을 등록된 애플리케이션을 대표하는 Agent와 알려진 사용자를 대표하는 Agent로 하는 Group으로 기록해야 한다.

등록된 애플리케이션 + 사용자 알려지지 않음 프로세스와 Requirements
(Application Registered + Unknown user Process and Requirements)

Process: LRS는 OAuth를 사용하여 등록된 애플리케이션의 자격 증명 및 빈 토큰 및 토큰 시크릿을 사용하여 서명된 요청을 존중한다.

Requirements

• 이 형태의 인증이 문장을 기록하는 데 사용되면, LRS는 권한을 등록된 애플리케이션을 대표하는 Agent로 기록해야 한다.

등록된 애플리케이션이 없음 + 알려진 사용자 프로세스와 Requirements
(Application Not Registered + Known user Process and Requirements)

Process: 학습 레코드 제공자는 "consumer_name"과 기타 일반적인 매개 변수를 지정하여 빈 문자열로 구성된 소비자 비밀 번호를 사용하여 임시 자격 증명 요청 엔드포인트를 호출한다. "consumer_name"에는 액세스를 요청하는 애플리케이션을 나타내는 문자열이 포함된다.

그런 다음 학습 레코드 제공자는 LRS에서 얻은 임시 자격 증명을 사용하여 Resource 소유자 승인으로 사용자의 브라우저로 이동시킨다. Resource 소유자 승인은 애플리케이션의 신원을 확인할 수 없다는 경고와 함께 "consumer_name"을 표시하는 페이지를 표시한다.

그렇지 않으면 프로세스는 표준 OAuth 워크플로우를 따른다.

Requirements

• 이 형태의 인증이 문장을 기록하는 데 사용되면, LRS는 OAuth가 애플리케이션을 지정하므로 해당 애플리케이션과 인증하는 사용자를 모두 포함하는 권한을 기록해야 한다.

애플리케션이 없음 + 알려진 사용자 프로세스와 Requirements
(No Application + Known user Process and Requirements)

Process: LRS에서 알려진 사용자가 사용할 수 있도록 제공한 사용자 이름/비밀번호 조합을 사용한다.

Requirements

• 이 형태의 인증이 문장을 기록하는 데 사용되면, LRS는 알려진 사용자를 대표하는 Agent로 권한을 기록해야 한다.

권한이 없는 프로세스와 Requirements
(No Authorization Process and Requirements)

• 요청은 빈 칸 문자를 포함하는 사용자 이름 및 비밀번호를 기반으로 하는 HTTP 기본 인증을 위한 헤더를 포함해야 한다.
• 요청에는 사용자 이름과 암호에 따라 각각 빈 문자열로 구성된 HTTP 기본 인증에 대한 헤더가 포함되어야 한다. 이 경우 HTTP 기본 인증 헤더는 Basic이 되고 문자열의 base64 인코딩 버전이 이어진다. 그러면 Basic Og==가 된다.

이는 명시적으로 인증되지 않은 요청을 HTTP 기본 인증 챌린지를 부여해야 하는 요청과 구별하기 위함이다.

4.2 OAuth 1.0 권한 범위 (Oauth 1.0 Authorization Scope)

Description

xAPI를 사용하여 통신하는 LRS(Learning Record Store)와 애플리케이션 간의 접근 수준을 협의하고, 애플리케이션이 필요로 하는 작업을 수행하는 동시에 남용 가능성을 최소화하기 위해 고안된 범위(스코프)에 대한 권장사항이다. 이 섹션의 요소들은 OAuth 1.0을 지원하는 LRS에 대한 요구사항을 Description하는 것임에도 불구하고 OAuth 2.0에서 영감을 받은 부분도 있다.

이 섹션의 요구사항은 LRS가 OAuth 1.0을 지원하는 경우에만 적용된다.

Details

다음 표는 xAPI 스코프 값들을 나열한다:

Scope	Permission
statements/write	어떤 Statement를 작성한다.
statements/read/mine	"나"로 작성된 Statement를 읽는다. 현재 토큰으로 Statement를 작성할 때 LRS가 할당할 권한과 일치한다.
statements/read	어떤 Statement를 읽는다.
state	현재 토큰과 관련된 Activities 및 Actors의 State 데이터를 읽거나 쓰기(이 관계를 결정하는 한도 내에서 제한됨).
define	Activities 및 Actors를 (재)정의한다. 이 권한이 부여되지 않은 경우, ID가 저장되고 LRS는 감사 목적으로 원본 Statement를 저장할 수 있지만, 정규적인 Actors 또는 Activities의 대표 표현을 업데이트해서는 안 된다.
profile	Profile 문서 데이터를 읽거나 씁니다. 현재 토큰과 관련된 Activities 및 Actors로 제한된다 (이 관계를 결정하는 한도 내에서).
all/read	제한 없는 읽기 액세스 (unrestricted read access)
all	제한 없는 액세스 (unrestricted access)

OAuth Resource

Name	Endpoint	Example
Temporary Credential Request	OAuth/initiate	http://example.com/xAPI/OAuth/initiate
Resource Owner Authorization	OAuth/authorize	http://example.com/xAPI/OAuth/authorize
Token Request	OAuth/token	http://example.com/xAPI/OAuth/token

Example

Scope 목록은 요청되는 권한 집합을 결정한다. 예를 들어, 강사는 애플리케이션(클라이언트)에게 "statements/read" 권한을 부여할 수 있지만, LRS는 여전히 그 도구를 학생에 관한 Statement로 제한할 것이다.

Requirements

• LRS는 OAuth 2.0에서 정의된 대로 스코프 Parameter를 허용해야 한다.
• 스코프가 지정되지 않은 경우, LRS는 "statements/write" 및 "statements/read/mine"을 요청된 스코프로 가정해야 한다.
• LRS는 최소한 "all" 스코프를 지원해야 한다.
• LRS는 다른 스코프를 지원할 수 있다.
• 클라이언트는 요청 시 필요한 최소한의 스코프만 요청해야 하며, 이렇게 하면 요청이 승인될 가능성이 높아집니다.
• "consumer_name" 및 "scope" Parameter는 OAuth 1.0의 일부가 아니며, 따라서 사용되는 경우 OAuth 헤더가 아닌 쿼리 문자열 또는 form parameters로 전달되어야 한다.

5.0 보안
Security

---

인증을 포함한 보안의 범위를 넘어서는 부분(예: OAuth 승인 스코프 해석)은 현재 문서의 범위를 넘어 개별 LRS 공급자의 구현 Details으로 남겨져 있다. 구현자는 산업의 최선의 실천 방법을 따르는 것이 권장되며, 이 예로는 백악관 CIO 사무실의 "HTTPS 전용 표준" 등이 있다.

이 사양의 구현 중에는 보안 관련 문제가 발생할 수 있으며, 보안을 위해 일부 준수 Requirements을 어기기로 결정할 수도 있다. 이러한 경우, 구현자는 구현 결정의 보안 및 상호 운용성 측면을 모두 고려할 것을 권장한다. 어떤 경우에도 LRS는 여전히 준수 테스트를 통과할 수 있도록 구성 가능해야 한다.

이 사양 이외의 다른 보안 관련 문제는 이 문서의 범위를 벗어난다. 그러나 xAPI 커뮤니티는 보안 최선의 실천 방법을 결정하기 위한 헌신을 지속하고 있다. 이러한 노력은 xAPIsec에서 시작되었으며, 참여가 강력히 권장된다.