RequestOptions

Immutable value for “no” request options.

Default initializer.

File for background download request. This file will temporarily be used while the background download is in progress up to the point it’s result stream has been read and closed. Alternatively (and only if backgroundName starts with “defer:” or “fetch:”), the background download will put data in the named file which is treated as a permanent file, and the result stream (e.g. for downloadMedia / downloadStream) will appear to be empty.

Name for background download request. A GUID string or other unique identifier should be used to avoid conflicts if multiple background downloads might be issued by the application at or around the same time. If this starts with the special prefix “defer:” (currently for Swift only), then the background download will be initiated, but the background download response will not be awaited and the initial request’s result stream will be empty. If this starts with the special prefix “fetch:” (currently for Swift only), then the response from a previously initiated background download (with the same background name suffix after “:”) will be fetched.

In offline scenarios, can this request be combined with a previous request? Defaults to true. A delete request can be combined with a previous create request by canceling the create request. An update request can be combined with a previous create or update request by merging the newly changed properties with the previously changed properties.

Set this to a cancellation token before initiating an async request if request cancellation may be needed.

Set the cancelToken and return this options object.

Enable capturing of response headers into the specified object (which should have type HTTPHeaders).

In offline scenarios, can this request be grouped with others having the same atomicity group? Intended as a performance optimization where grouping requests in a single transaction gives throughput benefits. Any such grouping is not guaranteed for requests having the same atomicity group, as there may be inter-request dependencies that prevent the grouping.

Example using proxy classes

open func transactionExample(patient: Patient) throws -> Void {
    let service = self.healthService
    let transactionID = GuidValue.random().toString()
    let appointment1 = Appointment()
    appointment1.patient = patient
    try service.createEntity(appointment1, headers: nil, options: RequestOptions()
        .transaction(transactionID))
    let appointment2 = Appointment()
    appointment2.patient = patient
    try service.createEntity(appointment2, headers: nil, options: RequestOptions()
        .transaction(transactionID))
    // Some time later... Upload both appointments in the same backend transaction.
    try service.upload()
}

Set the customTag and return this options object.

Set this to a custom tag when submitting a request for later upload in an offline scenario.

Must entities for offline create requests be retained after successful upload? Defaults to true.

Set the canCombineRequests property to false and return this options object.

Set the mustRetainCreates property to false and return this options object.

Should create/update requests receive no content in the response? Defaults to false.

Repeatability first sent time for this request.

Repeatability global request ID for this request.

Set the repeatabilityRequestID and repeatabilityFirstSent and return this options object.

Should no-change update requests be sent to the server? Defaults to false.

Set the changeSet and return this options object.

Example using proxy classes

open func transactionExample(patient: Patient) throws -> Void {
    let service = self.healthService
    let transactionID = GuidValue.random().toString()
    let appointment1 = Appointment()
    appointment1.patient = patient
    try service.createEntity(appointment1, headers: nil, options: RequestOptions()
        .transaction(transactionID))
    let appointment2 = Appointment()
    appointment2.patient = patient
    try service.createEntity(appointment2, headers: nil, options: RequestOptions()
        .transaction(transactionID))
    // Some time later... Upload both appointments in the same backend transaction.
    try service.upload()
}

Set the updateMode and return this options object.

Determines if updates use merge (HTTP PATCH) or replace (HTTP PUT) semantics. Defaults to merge semantics.

Set the uploadGroup and return this options object.

Example using proxy classes

open func uploadGroupExample(patient: Patient) throws -> Void {
    let service = self.healthService
    let appointment1 = Appointment()
    appointment1.patient = patient
    appointment1.purpose = "Fix Broken Leg"
    try service.createEntity(appointment1, headers: nil, options: RequestOptions()
        .upload("Urgent"))
    let appointment2 = Appointment()
    appointment2.patient = patient
    appointment2.purpose = "Check Sore Arm"
    try service.createEntity(appointment2, headers: nil, options: RequestOptions()
        .upload("Non-Urgent"))
    // Some time later... Upload only the urgent appointments.
    try service.upload(groups: StringList.of("Urgent"))
}

In offline scenarios, can this request be grouped with others to enable selective uploading by group name?

Example using proxy classes

open func uploadGroupExample(patient: Patient) throws -> Void {
    let service = self.healthService
    let appointment1 = Appointment()
    appointment1.patient = patient
    appointment1.purpose = "Fix Broken Leg"
    try service.createEntity(appointment1, headers: nil, options: RequestOptions()
        .upload("Urgent"))
    let appointment2 = Appointment()
    appointment2.patient = patient
    appointment2.purpose = "Check Sore Arm"
    try service.createEntity(appointment2, headers: nil, options: RequestOptions()
        .upload("Non-Urgent"))
    // Some time later... Upload only the urgent appointments.
    try service.upload(groups: StringList.of("Urgent"))
}

Set useBatchRequest to true and this options object.

Should this request be tunneled inside a batch request, e.g. for security reasons.