more IRL and alternate request syntax

[RoboSparrow]

Hi, I have a question in regards to statement aggregation and alternative request syntax

All xAPI requests issued MUST be POST.

This requirement includes more IRLs from StatementResult responses?

Example:

POST https://lrs.adlnet.gov/xapi/statements/more/ca717872ff5d526bfdd1f9af67e68590?method=GET

with body

Content-Type=application%2Fjson&Authorization=Basic%20dG9tOjEyMzQ%3D&X-Experience-API-Version=1.0.2

would be a valid xAPI request?

(currently returns 405, method not allowed)

[garemoko]

I would expect the alternate request syntax to be supported for 'more' requests.

[RoboSparrow]

The LRS I tested so far reject it all:

• adl.lrs: 405
• scormCloud: 400
• lxHive: 400
• learninglocker: 200, but expects query params to be retained in url

It would be great to include more behaviour into the alternate section as it seems the LRS handle it differently. This complicates aggregation on the client side.

[fugu13]

There's a bit of confusion here due to confusing wording in the spec. When the spec says

All xAPI requests issued MUST be POST.

That doesn't mean a client using the alternate request syntax must use POST (and the alternate request syntax) all the time, that means when you want to use the alternate request syntax you must use POST.

When you're handed a more link, that's considered an opaque link from the LRS that is suitable for GET requests. If you make a POST-burrowed GET to the Statements resource, you should still do a normal GET when following the more link.

[RoboSparrow]

Two points in favour of clarifying this in the spec:

• when automating aggregation on the client side you want to deal with one continuous syntax mode, i.e setting up the initial query and then let the aggregator recurse until more is empty.

• An LRS may include the initial query into the more IRL (we're doing this at lxHive and so does learninglocker). This raises the problem of query length boundaries also here