Never use code formatting for text, as it makes it unreadable on the mobile devices.
For my own (and others') convenience, here is unformatted rule table from parent comment:
GET - Return the current value of an object, is idempotent;
PUT - Replace an object, or create a named object, when applicable, is idempotent;
DELETE - Delete an object, is idempotent;
POST - Create a new object based on the data provided, or submit a command, NOT idempotent;
HEAD - Return metadata of an object for a GET response. Resources that support the GET method MAY support the HEAD method as well, is idempotent;
PATCH - Apply a partial update to an object, NOT idempotent;
OPTIONS - Get information about a request, is idempotent.
Until such time that the site supports quoted text a little civil disobedience is warranted. It's not like it's a hard problem.
Continuing to use code formatting after being made aware of the problem wouldn't be civil disobedience either. It would merely inconvenience the large number of people who read HN on mobile devices, for no purpose.
(Edited to remove a somewhat unrelated philosophical note.)
We all do it from time to time, even you did it few days ago [1], monospace have its purpose, maybe HN should simply fix it.
So yes, given HN's meager formatting options, monospaceisgood for that! :-)
You may note that later in that same comment there is a longer quote that I formatted in non-code italics.
But hey, if I encouraged you to create an HN account, that's great! Speaking as someone who writes code in a proportional font, we may have some interesting discussions ahead of us. ;-)
Because once upon a time the “H” in “HN” meant something.
Italics works fine for quote IMO.
Italics works fine for quote IMO
____
I propose using four underscores as a delimiter of a quote block, like asciidoctor, in addition to italics. I think it looks better than the markdown way of using ">" in front of a quote as it can get quite cumbersome and ugly when you're quoting multiple lines of something. However, I generally enjoy using markdown more if it works on a website. It just looks ugly IMO if it doesn't.
I think you'll find the practice of prefixing quoted lines with ">" originated with old Unix email and Usenet.
Thank you for the effort. I've updated my post with your text.
https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteOb...
Instead of polluting existing method names to mean new things, HTTP could offer more method names.
Having POST alternatively mean "send a command" makes it meaningless. The command could do anything.
What about fetching many objects or creating many objects or updating many objects?
Edit: I was wrong. It's allowed to put a body in a GET request, but it isn't OK to use it according to the HTTP spec (which admittedly kind of weird). Source: https://stackoverflow.com/a/983458
Edit2: according to an edit int the SO response, it looks like I wasn't actually wrong: or at least not since 2014 when these RFCs[1][2] became the standard for HTTP.
[1]: https://tools.ietf.org/html/rfc7231#section-4.3.1 [2]: https://tools.ietf.org/html/rfc7230#section-3.3
However, it is semantic nonsense to put it on a DELETE or GET.
DELETE is defined to remove the resource identified by the URL; GET is defined to fetch the resource identified by the URL. There no purpose for an entity.
[1]: https://tools.ietf.org/html/rfc2616#section-9.3 [2]: https://tools.ietf.org/html/rfc7231#section-4.3.1
> A payload within a GET request message has no defined semantics
> The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.
To :
> A payload within a GET request message has no defined semantics
Which, to me, sounds like: “it was forbidden to put info in the body, and now it's just not especially encouraged”. But maybe I'm over thinking the whole thing.
If your ids are UUIDs, each has a length of 36. If your URL consisted of nothing but UUIDs, you could safely delete 55.5(repeating) of them.
[0]: https://stackoverflow.com/questions/417142/what-is-the-maxim...
Probably in violation of some standard, but seems sensible enough.
Was recently dealing with a list of 100+ simple text fields each with unique identifying meta info.
Most usage of the form would only involve updating a few at a time, but on initial entry or a large update all of them could be updated or deleted.
A RESTful approach would have me submit 100+ individual PUT requests. However for a smaller instance of our server it would likely be affected by 100s of requests at a time and it would significantly complicate the client code to make all of these requests at a time and do the error handling for it.
It’s actually a small payload, even with 100 items, so it’s ridiculous to send them individual in order to be “correct” if it
- leads to a worse user experience. - increases load on the server. - complicates the codebase.
With HTTP2 you can send a ton of requests in parallel.
For one, having it be transactional.
>With HTTP2 you can send a ton of requests in parallel.
That's orthogonal. And they still have a cost (in time and size of transfer).
That means your CDN, your load balancers, and finally your actual applications-- any any other intermediaries -- all communicating via HTTP/2.
Not to say that HTTP/2 isn't the solution, but it's going to be slower than looking up "number of sites using HTTP/2", since you can't easily inspect the behavior of the intermediary servers.
I'm not entirely sure what you mean with downstream, but in my experience H2 is really well supported almost everywhere these days. Ymmv ofc
Anyway, I'm curious... what components do you run into that don't support this yet? At least in your examples I can't think of any major players that don't do HTTP/2 out of the box, except, well, old versions.
Is this more of a hypothetical? In my experience HTTP/2 is pretty much ubiquitous for anything current.
I think though that most operations don't need this. It's not an optimization I would blindly add to any operation, unless there's a specific case that warrants it.
I don't think that this is an anti-pattern. Most APIs do '1 thing at a time'.
The GET would be cacheable because they query would be repeatable and idempotent. In theory you'd never have to make the POST more than once unless you are creating a new query, which would make a new ID.
See section 13.
There have been proposed standardized fixes such as generalizing the HTTP SEARCH method that first appeared in WebDAV[0], but none have yet gone far.
[0] https://tools.ietf.org/html/draft-snell-search-method-01
For example, how do you have an up-vote link? What verb is that supposed to be? And links are all GET aren't they? Up-vote isn't idempotent. How do you make a correct up-vote link?
How do we have this disconnect between HTTP verbs and HTML? How did it work before AJAX?
(I'm not a web developer.)
c.f. https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
User agents still don't support PUT et all in forms without JavaScript -- you're limited to GET/POST, c.f. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fo...
So why were they in the original HTTP spec if they weren't supported by original HTTP agents?
Bad assumption.[1]
HTTP/1.0 spec (1996) defined GET, POST, and HEAD.[2]
HTTP/1.1 spec (1997) defined all of the other, newer methods.[3]
> supported by original HTTP agents
The first web browsers I know about were Mosaic (1993) and Netscape Navigator (1994) predating the HTTP/1.0 RFC.
[1] https://stackoverflow.com/questions/41411152/how-many-http-v...
This is before me being old enough to follow technology, so below is a good portion of conjecture and hearsay (I'd love to be corrected by someone who actually remembers it):
Tim Berners-Lee initial web browser was intended as an editing tool as well as a viewer, and these ideas came back when they went to write up HTTP as a a "proper" IETF standard. Not uncommon (bit less so today, but back then especially) to design specs with what they thought it should do, not what they'd tried/done in practice. Making an official spec is the chance to get this stuff in.
At some point, a bunch of the file-specific stuff was split off to WebDAV as an extra thing (work on that started 1996, HTTP 1.1 was finished 1997) - or rejected and WebDAV created as a new home for those ideas? But PUT among some others survived.
An “upvote” is probably an idempotent action. Calling an “upvote” endpoint moves an object into an “upvoted” state, regardless of what it’s previous state was. However, it’s probably semantically a PATCH, since it’s a partial update of a resource.
There is no real disconnect here.
That being said, I too have seen things like this on the Internet. I would assume Google has some sort of heuristic to determine whether or not they can safely prefetch a link, but who really knows? You should absolutely avoid making this mistake in your own code.
EDIT: Since I didn't make my case well enough, here's an example. Let's say you want to charge a credit card. Are you doing a `POST /charge`? Or would it be better to say `card.charge(500)`? My point isn't that there shouldn't be a proper REST API below it, but rather that we should offer abstractions so normal semi-technical people can use APIs and don't have to think too much like a computer.
On the other hand, if I offer a web service and some someone asks “but what if I can’t make HTTP requests?” I’m _perfectly_ happy to tell them to piss off.
People think in ambiguity; adding a new item or replacing an existing item, as in this example, shouldn't be something an application needs to guess at.
I really don’t want to worry about setting http headers to make an add-if-not-exists call for example. The API in a client library with a method “TryAdd(...)” is understandable as an API, and the setting of headers and 4XX code you might receive on a duplicate is just returned as false.
POST /my-account/charge is not an abstraction, it's pretty much exactly what people do and have done.
You're perfectly fine to design an API around RPC calls and POST. There are all of the issues around RPC that you will have to deal with (long running operations, versioning, serde and marshalling of arguments, argument and response typing and interface definitions, codegen of the IDL to product client and server stubs that will require modification and back/forward porting of implementation).
But an API definition like this one, covers a lot of that as part of the protocol, most of which is defined by HTTP anyway. You also get encryption, compression, caching, tooling "for free".
The only exception is on resource creation (POST) since there's no existing version/generation number to match on. You can get around that by letting the client generate the id with a random id and reject if the id already exists. I haven't decided if this is a good idea or not since the client can potentially choose really weird vanity ids (especially if you're using uuid in hex or base64). But if you don't expose your internal ids in any UI that seems fine too.
GET - Return the current value of an object, is idempotent;
PUT - Replace an object, or create a named object, when applicable, is idempotent;
DELETE - Delete an object, is idempotent;
POST - Create a new object based on the data provided, or submit a command, NOT idempotent;
HEAD - Return metadata of an object for a GET response. Resources that support the GET method MAY support the HEAD method as well, is idempotent;
PATCH - Apply a partial update to an object, NOT idempotent;
OPTIONS - Get information about a request, is idempotent.
Most importantly, that PUT is idempotent.
Credit to arkadiytehgraet for retyping the table to be readable. Please give them an upvote for the effort.