Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Just wondering, if the resource ID is known, I thought PUT is the recommended method?

Recommended for what purpose?

The set of recommendations I'm familiar with is:

    GET:   requests without side effects
    POST:  requests with side effects
    PUT:   never use
    other: never use
POST gets special treatment from browsers for various security risks. Otherwise, methods don't differ. You can use PUT as part of an effort to feel like you and your server have a secret code, but it's fundamentally the same thing as doing `GET /path/to/resource/put`.


PUT has a big advantage in that it is mandated to be idempotent - it is safe to be repeated if it fails for whatever reason.

Meanwhile, POST is generally not considered safe to repeat in case of failure, because the client/proxy does not know where exactly the failure happened and if thus the processing has been already done or not.


Yes, that's why you use POST for everything with effects.

But if this is really your concern, you should also be using PUT to create new database records. In principle, those requests are safer to repeat than updates are, since the database will ignore repeated inserts and apply repeated updates. (Though as far as I can tell this only matters if your update adjusts a value rather than setting it outright.)


> Yes, that's why you use POST for everything with effects.

I don't get it. Isn't an idempotent effect still an effect?

> you should also be using PUT to create new database records.

If the client is free to define the identity, then I do. But if the resource gets e.g. an ID from Postgres sequence, then I need to use POST, because repeated call would create duplicates.


I don't think this is quite accurate, browsers won't treat PUT requests as safe the same way it does a get request.


PUT's can have request bodies, GETs can not.


Incorrect; GET requests are free to have bodies.

See the note here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GE...


It's still a rather bad idea. An older version of HTTP spec said that GET request body SHOULD be ignored. Proxies implementing that older version of spec could just drop the body ... You might also encounter problems with many tools not supporting it simply because the authors were not aware of it or perhaps considered it useless.


If you want a GET-with-body that actually works, use QUERY. The draft is expired, but at least it's just a non-standard method (which is fine!), not actively broken like GET-with-body.

https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-met...


Also see the first row in the table on that page.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: