41–50 of 90 posts
Earlier quoted context omitted.
Auth requests are for a new session ID, not a new user ID. It's a (C)reate in CRUD, not an (U)pdate. POST - Create, GET - Retrieve, PUT - Update, DELETE - Delete
The protocol could be: CREATE /xxx READ /zzz UPDATE /yyy DELETE /abcd
Earlier quoted context omitted.
Auth requests are for a new session ID, not a new user ID. It's a (C)reate in CRUD, not an (U)pdate. POST - Create, GET - Retrieve, PUT - Update, DELETE - Delete
The protocol could be: CREATE /xxx READ /zzz UPDATE /yyy DELETE /abcd
> 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.
Auth requests are for a new session ID, not a new user ID. It's a (C)reate in CRUD, not an (U)pdate. POST - Create, GET - Retrieve, PUT - Update, DELETE - Delete
POST - Create, GET - Retrieve, PUT - Upsert, DELETE - Delete, PATCH - Update
Earlier quoted context omitted.
> 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…
PUT's can have request bodies, GETs can not.
See the note here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GE...
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've travelled to SF (from Poland) and this has struck me too, together with lawyer ads.
I take it you haven't had the pleasure of driving thru Philadelphia. Some say you can even see skyscrapers behind the sea of lawyer ads.
> while curl is my hobby, I also work on curl as a full-time job. It is a business and I serve and communicate with many customers on a daily basis. While it's not my business, I still wonder how this business looks like. Is curl sponsored? If so, is this a common thing for foundational tools alike?
If you look around, you'll see the sponsors page: https://curl.se/sponsors.html Some sponsorship is through opencollective, which includes transparent information about donations: https://opencollective.com/curl#category-BUDGET So opencollective has it at $280k USD since sometime in 2018, not bad, that's like half of what the average Googler makes in 1 year (except spread over 5 years). You can also see there hadn't…
> 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…
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.
Imagine having a hobby project, installed on billions of devices. MBA: they must be making 10B$/year? Engineer: no, this is just a hobby
A bit unfair as the main reason it is installed on billions of devices is that it is FOSS. It's like giving to charity and then being aggravated that it was used to generate lots of money, you can't retroactively change your mind. Although they can always stop updating curl if it is that bad for them.
You are right, but I wanted to show current mindset. Redis, ElasticSearch, Mongo, HashiCorp stack were also FOSS and landscape is changing. Same could have happened to cURL
Earlier quoted context omitted.
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...