5 ms·

> we can create a mailbox via HTTP GET request to https://api.unverified.email/create https://api.unverified.email/create Shouldn't GETs be idempotent? (Sorry

by afraca 6y ago

> we can create a mailbox via HTTP GET request to https://api.unverified.email/create https://api.unverified.email/create Shouldn't GETs be idempotent? (Sorry for not having feedback on the idea, skimming it it seems nice, though there is fierce competition as others have shown here)

mike_d 6y ago
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)
- cyansmoker 6y ago
  Not being pedantic, then, but is GET even the right verb to create a resource?
  - de_watcher 6y ago
    PILLAGE was too long, so we use GET.
  - deleted 6y ago
    [deleted]
  - cryptonector 6y ago
    That's how URL shorteners work.
- moreira 6y ago
  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.
- throwaway_pdp09 6y ago
  I think that is being pedantic. No-one's going to misunderstand what the intended idempotency of GET is supposed to be.
  - wlll 6y ago
    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.
- cryptonector 6y ago
  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 https://tools.ietf.org/html/rfc7231#section-4.2.1
Cthulhu_ 6y ago
In this case, it generates a new resource; ideal for one-off e-mail addresses. If you do a GET on most websites you get a different result as well, e.g. the news has updated or in the case of HN the comments or news order has changed.
- chrisandchris 6y ago
  There is a difference between „getting a different result“ and „making the result different“. You mean the first one whale the mentioned site does the latter one. The first one is Ok, the second one not. A subsequent GET may return different data because another POST/PUT modified the data but a GET should never modify the data itself (e.g. i won‘t be able to safe this comment by GET but by POST).
arethuza 6y ago
It using a GET does mean that when you lick on the link it actually works - which is kind of neat although not strictly RESTful (but then nothing ever is).
joosters 6y ago
If all the API calls create a mailbox on demand, and never return a "mailbox doesn't exist" error, then the GET doesn't make any observable changes - it's as if the mailbox has always existed.
- Drakim 6y ago
  Provided that there aren't any other consequences, such as emails not being delivered before you do that GET.
  - cryptonector 6y ago
    Idempotent != no side effects. Idempotent == if you do it more than once, you get the same result.

by afraca 6y ago

mike_d 6y ago

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)

cyansmoker 6y ago
Not being pedantic, then, but is GET even the right verb to create a resource?
- de_watcher 6y ago
  PILLAGE was too long, so we use GET.
- deleted 6y ago
  [deleted]
- cryptonector 6y ago
  That's how URL shorteners work.
moreira 6y ago
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.
throwaway_pdp09 6y ago
I think that is being pedantic. No-one's going to misunderstand what the intended idempotency of GET is supposed to be.
- wlll 6y ago
  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.
cryptonector 6y ago
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 https://tools.ietf.org/html/rfc7231#section-4.2.1

Cthulhu_ 6y ago

In this case, it generates a new resource; ideal for one-off e-mail addresses. If you do a GET on most websites you get a different result as well, e.g. the news has updated or in the case of HN the comments or news order has changed.

chrisandchris 6y ago
There is a difference between „getting a different result“ and „making the result different“. You mean the first one whale the mentioned site does the latter one. The first one is Ok, the second one not. A subsequent GET may return different data because another POST/PUT modified the data but a GET should never modify the data itself (e.g. i won‘t be able to safe this comment by GET but by POST).

arethuza 6y ago

It using a GET does mean that when you lick on the link it actually works - which is kind of neat although not strictly RESTful (but then nothing ever is).

joosters 6y ago

If all the API calls create a mailbox on demand, and never return a "mailbox doesn't exist" error, then the GET doesn't make any observable changes - it's as if the mailbox has always existed.

Drakim 6y ago
Provided that there aren't any other consequences, such as emails not being delivered before you do that GET.
- cryptonector 6y ago
  Idempotent != no side effects. Idempotent == if you do it more than once, you get the same result.