Does sending system-profile information with HTTP GET request conform to RESTful practices?

Question

I'm using the Sparkle framework to update an app, and want to make use of the framework's ability to send system-profile information. The way this is done is by adding the information to the HTTP GET request that asks for the update package. However, I've been told by my colleagues that it's best to reconfigure the framework to send the profile information using an HTTP POST request, as this is "the RESTful way to do things".

Is that correct??? I can't imagine, however, that the framework's creators would do implement these requests in a way that didn't conform to RESTful practices, and my research so far hasn't turned up any definitive answer.

• Mike Partridge: In what way does Sparkle include system-profile info with the GET request? E.g. as a request body, as a URL parameter, etc?
• narner: From my understanding, when it makes a request for an update, the system profile info is appended to the request: github.com/sparkle-project/Sparkle/wiki/System-Profiling (Apologies, first time with network requests as iOS developer!)
• Mike Partridge: Looks like it's URL parameters.
• narner: That seems right @MikePartridge

Answer 1

According to the documentation, anonymous information about the user's system is sent with an update request.

I'd say that technically your colleagues are correct. This info doesn't appear to be used to affect the response to the request, so it doesn't really belong there. A better way to send that info would probably be to POST to a separate resource, such as /systemProfile or similar.

If you want to be strict about REST compliance you might seek to reconfigure the framework to provide the system profile info that way, but I wouldn't get too hung up on it. If the framework is useful and this is the way it provides profile information to the backend, the REST police aren't going to break down your door.

• Demian Brecht: "If the framework is useful and this is the way it provides profile information to the backend, the REST police aren't going to break down your door." +1.

Answer 2

RFC 7231, Section 4.3.1:

A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.

So in short, sending a payload is indeed incorrect. As far as REST goes, use POST if you're creating an item, and PATCH for partial updates or PUT for full updates (although this isn't set in stone and many people get away with solely using PUT).

---

Update based on comments:

Updating an object, whether it's via request body or GET params is not RESTful. A RESTful service abides by HTTP semantics.

The GET method requests transfer of a current selected representation for the target resource.

GET is intended to return the a representation of a resource's current state, not make changes to it.

• Mike Partridge: REF 7321 appears to be Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) - is that the RFC you're referring to?
• Demian Brecht: @MikePartridge: Derp, typo. It's RFC 7231. Thanks for the catch.