What is LocaleId When using CreateCourseOffering

[bootsa...@yahoo.ca]

What is LocaleId in:

Course.CreateCourseOffering

{
    "Name": <string>,
    "Code": <string>,
    "Path": <string>,
    "CourseTemplateId": <number:D2LID>,
    "SemesterId": <number:D2LID>|null,
    "StartDate": <string:UTCDateTime>|null,
    "EndDate": <string:UTCDateTime>|null,
    "LocaleId": <number:D2LID>|null,
    "ForceLocale": <boolean>,
    "ShowAddressBook": <boolean>
}

There is no explanation for it in the documentation.

[Desire2Learn Staff: Sarah-Beth]

LocaleID corresponds to the locale settings required for your course offering. Details on the Manage Locales tool are available in the Admin Documentation, which provides context for what they are and how they're used. 

Finding the appropriate LocaleID is covered in an older question on StackOverflow. I've repeated the response below.

From Viktor on StackOverflow:

Unfortunately, there is not currently a Valence API to retrieve the list of locale IDs together with locale names and other meta-data. Additionally, it's possible that only a user with the permissions to use the Locale Management admin tool will be able to provide you with the locale IDs that you'll want to use in your calls.
The admin user can go into the Locale Management tool to view the list of locales, click on one to select/edit it, and then, look in the query URL to see what the value of the id parameter is: this should be the locale ID.

[bootsa...@yahoo.ca]

I receive 404 - NotFound every time I try to create a new course offer like:

{"Name":"COURSE-0001 (107664) My Course", "Code":"107664", "Path":"/content/course_offer/107664/", "CourseTemplateId":10889, "SemesterId":47878, "StartDate":"2015-02-02T06:00:00Z", "EndDate":"2015-07-14T05:00:00Z", "LocaleId":null, "ForceLocale":false, "ShowAddressBook":true}

Posted to: /d2l/api/lp/1.4/courses/

I was assuming it was because I was passing a null for LocaleId but I have no idea.  The course template id and semester id are both valid.  404 isn't exactly the most friendly error message.  Where do I go from here to track down this issue?

[bootsa...@yahoo.ca]

After three days of smashing my face I figured it out.  Apparently I was missing a decimal place on the UTC dates.  I had LocaleId as a string and I had SemesterId as an integer instead of Nullable(Of Integer). 

Is there any hope of D2L abandoning this attempt at restful and switching back to an actual usable, user friendly soap API?

[Desire2Learn Staff: Sarah-Beth]

Thanks for sharing your resolution. UTC date format has been a gotcha in the past, so was going to be my route for investigation, but you got to it first.

On the REST vs SOAP front, we have no plans to switch back to SOAP. I'd be interested to understand where you find REST falls down (in comparison to SOAP or on its own merits) so that we can weigh those opinions in future design decisions.

~S-BB

[bootsa...@yahoo.ca]

By far the biggest issue I've found so far has been the error messages.  Generic http error responses (400,403,404,500) are not helpful.  I'd prefer to get a message that could at least point me in some direction as to the cause of the error.  Without this, trial and error is all that is left to go by in order to solve an issue.  When timeframes for projects are tight, this is very stressful.

Since D2L is expecting some very rigid requests and responses, SOAP seems to be the more user friendly way to go.  With this rest "like" approach the end user is forced to write hundreds of lines of code in order to format these requests and responses into exactly what D2L in expecting.  This leaves tons of room for errors and even minor errors cause big delays (see first paragraph).

I'll admit as a .NET programmer I am far more comfortable using SOAP since support for SOAP is built into the framework.  Now I'm almost forced to use a third party library like RestSharp in order to use this integration.

[Desire2Learn Staff: Sarah-Beth]

Thanks for the feedback. Error messages are something we've identified as an area for improvement. I'll be sure to raise this again. Usability of our APIs is a general theme that we're exploring internally, so I'll be sure to raise your concerns as part of upcoming conversations.