[mike_d]

No. GET is defined to be nullipotent, or having no side effects. That is not the same as "not making a change."

To be pedantic, every GET request to a modern website makes a state change somewhere... to a log file, to a database, to a tracking system. The difference is it has no side effect for the user (i.e. your comment gets duplicated or your order placed twice)

[moreira]

Considering this is relating to an API, the mention of whether to use GET or another method implies a REST API, in which case GET is described as:

> safe, meaning that applying it to a resource does not result in a state change of the resource (read-only semantics)

It should never be used to -create- anything, only to retrieve existing resources (and not change their state). For creating we have POST requests. Obviously no one is going to care or do anything about it if you use GET, but if we're going to be pedantic le t's not mischaracterise GET requests.

[cryptonector]

Not quite. GET is defined to be "safe" and "idempotent", and while "safe" does mostly mean "no side effects", it actually means something more like "doesn't cause harm" per-RFC7231:

   Request methods are considered "safe" if their
   defined semantics are essentially read-only; i.e.,
   the client does not request, and does not expect,
   any state change on the origin server as a result
   of applying a safe method to a target resource.
   Likewise, reasonable use of a safe method is not
   expected to cause any harm, loss of property, or
   unusual burden on the origin server.
  
   This definition of safe methods does not prevent
   an implementation from including behavior that is
   potentially harmful, that is not entirely read-only,
   or that causes side effects while invoking a safe
   method.  What is important, however, is that the
   client did not request that additional behavior and
   cannot be held accountable for it.  For example, most
   servers append request information to access log files
   at the completion of every response, regardless of the
   method, and that is considered safe even though the
   log storage might become full and crash the server.
   Likewise, a safe request initiated by selecting an
   advertisement on the Web will often have the side
   effect of charging an advertising account.
  
   Of the request methods defined by this specification,
   the GET, HEAD, OPTIONS, and TRACE methods are defined
   to be safe.

https://tools.ietf.org/html/rfc7231#section-4.2.1

[throwaway_pdp09]

I think that is being pedantic. No-one's going to misunderstand what the intended idempotency of GET is supposed to be.

[wlll]

This may tip the pedantry scale too far, but the comment you are replying to is in reply to a comment that suggests confusion over the idempotency of GET.

I'm not suggesting that it's named wrong or anything like that, this is just about your comment.

[cyansmoker]

Not being pedantic, then, but is GET even the right verb to create a resource?

[de_watcher]

PILLAGE was too long, so we use GET.

[cryptonector]

That's how URL shorteners work.