assignments() needs to accept more criteria

[tacman]

Current assignments() is implemented to accept a jobId as a parameter, but it needs to be much more flexible. It should probably simply map whatever is passed to the API, and this model should be true for other GET calls as well.

For example, we might want

assignments <- assignments(jobId=163,memberId=224,status='unapproved')

The code should not require the fields to be in any specific order. If R doesn't support that, then perhaps we should be passing a list:

assignmentCriteria = list()
assignmentCriteria$jobId = 163
assignmentCriteria$memberId = 224
a <- assignments(assignmentCriteria)

Again, I'm not 100% sure of the best way to do this, but we don't want to have the users have to deal with function calls with a long list of arguments, most of which are optional.

[phillc73]

From an R point of view, the function options do not need to be in any specific order. You could put "status" first, followed by "memberID" if you wished.

I need to know a couple of things to move forward with this. Using assignments as the example:

• What are some valid inputs and input types for the existing options exposed by the API? e.g. I do not know what "wave_id" or "wave_ids" to use for testing. Therefore, I haven't exposed this option in the R package.
• Are "wave_ids" always numbers? Should any other input flag an error before the call is parsed to the API? As it currently stands, there is error checking on the response from the API. For example, if you used member_id="XYZ" as part of the locations function, the API will not return a 200 OK status, and therefore the R package will stop and ask the user to check the validity of their function options. My question is whether this checking should be done before the function call is parsed to the API, in which case I need to know all the different valid option types. e.g. Text only, number only.
• Not every function option needs to be entered by the end user, if the option already has a default included as part of the package. For example, the "max_per_page" option, which is available for most API calls and included wherever possible in this package, always defaults to 25. The end user can overwrite this by setting it in their function call. I need to know which API options are required and can't be defaulted to any value. I also need to know which can be defaulted to some value, thus optional for the end user. I need to know what these default values should be. e.g. locations has a "start_date" option. I need to know what the earliest possible date can be, in order to make this the default.
• As well as knowing the valid option types, I need to know a complete list of valid options for all API calls. In the example you've used here, according to the API documentation/sandbox neither "member_id" nor "status" is currently exposed via the API.
• Many of the API end points have a "criteria" option. I do not know what any of these "criteria" could be.

[phillc73]

I'd also like to add that the users{} endpoint supports both POST and DELETE methods, obviously as well as GET.

Can you please supply me with some test data for POST, which I can then also test via DELETE. Or would you just like me to make up data?

I haven't tested, but assuming the previously supplied "nyu" credentials will support POST and DELETE for users{}?

[tacman]

No, the nyu credentials should not support anything for users, only members.