Support PATCH verb for HTTP requests

[ian.yeager]

LabVIEW's HTTP Request client currently does not support the PATCH method. This method is becoming increasingly more popular within RESTful API's and has been an officially recognized verb since 2010 (RFC 5789). It should be fairly simple to integrate, since LabVIEW runs cURL under the hood and cURL implements it with curl --request PATCH

[smithed]

Not just patch, but more generally allow for more flexible use of the library. The main rfc defines the core set, but also specifies a registration scheme: https://www.iana.org/assignments/http-methods/http-methods.xhtml

REPORT is of particular interest to me, as its conceptually a GET request where the payload is used, allowing for more complex querying and generation of...well...reports.

There have been numerous times where I've come very close to just implementing it myself..except labview lacks native tls support 😞

[DerekTrepanier]

I've Kudo'd this idea, but I just wanted to add info about why I want it.

This is mostly about being remotely feature complete. This allows us to design GOOD restful interfaces using the current best practices, instead of hack-ey workarounds. PATCH requests are used when you need to update a resource, but you're only providing part of the information to the server.

For example, if I had the resource

{

  "id": 123,

  "name": "derek",

  "email": "derek@mooregoodideas.com",

   "state": "Utah"

}

And I wanted to allow the client to update just the "state" field. I'd create an interface that accepted a PATCH request with the body:

{

  "state": "Texas"

}

Obviously, I could make my application code perform the same action with a PUT request, but according to RFC 2616, a PUT request should provide the complete entity. Since I want my API to ONLY support updating the state, I have to make a decision:

1. Violate best practices, ignore RFC 2616, and allow the PUT operation to accept partial updates.

2. Require the user provide the full record, but throw an error every time they try to update an inappropriate field. (this makes application code more complex)

Neither is preferable.

[PhillipBrooks]

I had the need to use a PATCH method to post to the Salesforce API.

I found an example ( non-LabVIEW related ) CURL script that appended ?_HttpMethod=PATCH to the URL.

I read that LabVIEW used CURL under the hood, so I tried it and it worked! Been using it for several years now. Don't know if NXG uses CURL under the hood like regular LabVIEW.

https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_update_fields.htm

[smithed]

That appears to be specific to salesforce (a nicety they built into their api so that people with hamstrung libraries like ourselves can still use their stuff, basically)

salesforce documentation:

If you use an HTTP library that doesn't allow overriding or setting an arbitrary HTTP method name, you can send a POST request and provide an override to the HTTP method via the query string parameter _HttpMethod. In the PATCH example, you can replace the PostMethod line with one that doesn't use override:

---

[PhillipBrooks]

Ah, that makes sense now. I was so happy to get it working that I just moved on not fully understanding why it worked.

I decided to poke around for a bit, looking at the DLL in National Instruments\Shared\nicurl .

It appears that most (or all) the libcurl functions are available, but I'm guessing that because the POST, GET etc probably encapsulate the whole action, you wouldn't be able to use the LabVIEW client handle to set the CURLOPT_CUSTOMREQUEST to 'PATCH', you would have to reconstruct the whole action.

Seems doable, but as you stated NI should make this library more complete for all of us.

[smithed]

Looks like its added to NXG, so presumably the shared DLL has been updated...at least internally

[Eric.M]

I would give 900 kudos if I could, I was shocked today when I saw how incomplete the list of supported verbs is...

[Christina_R]

NI has published an alternative HTTP API that supports PATCH and other verbs: https://www.vipm.io/package/ni_lib_advanced_http_client_api/