11–20 of 90 posts
> I would personally perhaps protest against the use of PUT for POSTing JSON, but nobody asked me. Just wondering, if the resource ID is known, I thought PUT is the recommended method? We usually use POST for creating a new resource for which you don't know an ID yet.
> I would personally perhaps protest against the use of PUT for POSTing JSON, but nobody asked me. Just wondering, if the resource ID is known, I thought PUT is the recommended method? We usually use POST for creating a new resource for which you don't know an ID yet.
It's a (C)reate in CRUD, not an (U)pdate.
POST - Create, GET - Retrieve, PUT - Update, DELETE - Delete
> I would personally perhaps protest against the use of PUT for POSTing JSON, but nobody asked me. Just wondering, if the resource ID is known, I thought PUT is the recommended method? We usually use POST for creating a new resource for which you don't know an ID yet.
- POST: Perform resource-specific processing on the request content.
- PUT: Replace all current representations of the target resource with the request content.
I interpret this as the only immediate side-effect of PUT is supposed to be replacing the target resource with the request content. Everything else is POST, but that does not mean that we can't use POST for everything. Thus, JSON via PUT is not inherently odd at all. Calling a random API using PUT with JSON arguments that executes some code other than replacing a resource, would be odd.
I do think, though, that PUT may very well implicitly create a resource, if the name of that resource is the argument to the put. That is just something that's rather odd, as, often, the server has authority over the names of new resources.
I find PUT particularly helpful, as, given these constraints, I assume that PUT is idempotent; POST is not.
Off topic but I find it wild that SF has API ads on bus shelters. Is that unusual/right in a dev hotspot, or have I been well underestimating just how intrinsic the tech culture is there? (I’m an Australian, so I guess my question applies to the US as much as SF)
> I would personally perhaps protest against the use of PUT for POSTing JSON, but nobody asked me. Just wondering, if the resource ID is known, I thought PUT is the recommended method? We usually use POST for creating a new resource for which you don't know an ID yet.
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
That's aggravating. What's the workaround?
edit0: Chrome made more progress, then collided with Vodafone's shitty approximation to infrastructure which is known unsolvable.
edit1: Magic: https://web.archive.org/web/20240422091821/https://daniel.ha...
We are in trouble when some organisation manages to kill archive.org
> https://daniel.haxx.se/blog/2024/04/22/curl-is-just-the-hobb... has a security policy called HTTP Strict Transport Security (HSTS), which means that Firefox can only connect to it securely. You can’t add an exception to visit this site. That's aggravating. What's the workaround? edit0: Chrome made more progress, then collided with Vodafone's shitty approximation to infrastructure which is known unsolvable. edit1: M…
> I would personally perhaps protest against the use of PUT for POSTing JSON, but nobody asked me. Just wondering, if the resource ID is known, I thought PUT is the recommended method? We usually use POST for creating a new resource for which you don't know an ID yet.
> 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…
> https://daniel.haxx.se/blog/2024/04/22/curl-is-just-the-hobb... has a security policy called HTTP Strict Transport Security (HSTS), which means that Firefox can only connect to it securely. You can’t add an exception to visit this site. That's aggravating. What's the workaround? edit0: Chrome made more progress, then collided with Vodafone's shitty approximation to infrastructure which is known unsolvable. edit1: M…
I thought this was fairly common?
Most security scanning software will ding any site that doesn't use HSTS
MBA: they must be making 10B$/year?
Engineer: no, this is just a hobby