This comment and several others you've posted violate the HN guidelines. We ban accounts that do that, so please (re)-read the following and post civilly and substantively from now on.
The idea that fickle consumers are to blame for unethical and often unlawful exploitation of employees is propaganda with only the thinnest veneer of economics painted on it.
I suppose I understand why the very rich and business interests make arguments like this, but usually it's just ordinary people. Who benefits? It's about time we held companies like Amazon accountable for the way they harm and exploit their employees instead of helping shift the blame to their customers.
I'm not convinced Amazon would suffer significantly if they raised their prices by 10% on average. No other seller can compete with them on convenience, and people are willing to pay for that.
I didn't say that consumers would choose to pay extra for decent employee treatment. I said that Amazon could just do it and get away with it. Mind you, I'm also not convinced that the cost of treating your employees like human beings is as high as 10%.
Also, for fuck's sake stop making excuses for abusive employers. Why would you do that?
Not an argument. Feminism is an ideology and like any other has its good points and bad. You can believe in equality and not have to identify as a feminist.
You can also believe in a better world than the one we currently have, not call yourself a feminist and also not believe "equality" is the standard we should be caring about.
(In case it actually needs to be said again: I happen to be female.)
Oh of course. Wouldn't want to be associated with feminism. But hey, you can still be a feminist, just don't call it that, right? Becauase just like men's deodorant and shaving cream, we have to have our OWN version of feminism, free from all of those WOMEN. Wouldn't want to be associated with women or have to navigate a space that isn't ours. Nope.
(Hint: this is sarcasm and feminism isn't primarily about men.)
And yet in four billion years when the sun expands and engulfs the inner planets, nothing will matter, nor will have mattered. We ARE a insignificant in the universe; I don't see how that's untrue.
Matter to whom? Mattering to myself was an important step in my personal growth, and there are other people in my life who think I matter, and people I've never met who simply believe we all matter.
How sad to convince ourselves not to matter to ourselves by saying look, I don't matter to the universe, so how could I possibly matter? Does anything matter to the universe? If not, it's probably not the best entity to look to to figure out what matters. If the universe does care about something, who says it doesn't care about you, just because it's big and you're small in comparison?
Actually any choice we make creates a new unique timeline where different choice(like stepping on butterfly) will make radical changes in the future, diverging from mainstream timeline.
As in Sci-fi time travel which changes the past a little, leading to enormous changes in future: this is the past, and we are shaping the future with our choices.
Would it matter in far future if sun is destroyed, if we choose to invest in space expansion and colonize new systems? The future isn't set in stone, fatalism is just learned helplessness, robbing us of free will and drive to improve our condition.
Our experience is that many discoveries have changed the world and created a different future than that which we otherwise might have experienced. They would have had to be inevitable for them not to matter and that's certainly contentious though true in some cases. Given they have made a difference how does an extended time scale necessarily negate their influence?
Your assertion might turn out to be true or not.
Ansible has a featur called Vault that encrypts whatever you tell it to with a password. You can then upload that to version control, and when you want to deploy, you just pass the password to Ansible (either via a file or any environment variable, ideally).
I'm using it to migrate us over from keeping our SSL cert in Dropbox and 1Password and it works well.
Society would collectively decide to fund drug development because it betters all of humanity. There are ways to innovate without fucking over everyone for the sake of profit, you know.
Then you have to solve a very difficult resource allocation problem. Capitalism solved it with a distributed scalable universal reward mechanism (profit). At least in European societies drug discovery is then still financed by society because there exists universal healthcare, which is subsidized by the state for underprivileged people.
Profitability funds the next generation of drugs. It pays the salaries of researchers and clinicians and funds human trials.
E.g. A drug like Kadcyla that gives six months to late stage breast cancer patients. 20 years ago that option wasn't available but now it is an option, in part, due to profits of other drugs.
Have we considered that these REST "anti-patterns" exist because REST is fundamentally inappropriate for what most people are trying to use it for? What if you can't shoehorn your functionality into the handful of REST verbs? What if none of the status codes make sense?
What ever happened to plain old RPC? Have we stopped to consider that people tunnel things through POST or GET requests because it's easier and more flexible than trying to cram your functionality into GET, POST, PUT, PATCH, or DELETE?
If you find yourself using a lot of these anti-patterns, maybe you should consider switching to something a little less "REST-ful".
Most things on the web are half-assed, and half-assed HTTP APIs enable rapid results (before the problems start).
REST is not fundamentally inappropriate, it just needs a lot of careful design about domain objects, link relations, and media types. Generally, people are not very good at thoughtful design.
It didn't help that REST began to trend as an idea right around the same time that intentionally schemaless JSON was replacing schema'd XML documents as the preferred way of over-web information interchange. For consumers, schemaless JSON snippets were attractive for partial processing; for developers, they were attractive for rapid iteration. For makers of "Web 2.0 Mashups", JSON-returning APIs were attractive because processing XML with circa-2006 "cross-browser" nightmare-mode Javascript was about as pleasurable as pulling teeth.
People saw these APIs being called REST, they tried to understand REST, got overwhelmed halfway through, called it REST-like or RESTful instead, and that's how we arrived at where we are.
During this time, RPC wasn't cool or buzzword-compliant, so the people who still RPC did it for good reasons and didn't really blog about it. The quip to consider RPC is nonetheless valid; stuff like gRPC or Thrift are at least proper RPC frameworks, and a much better idea than someone trying to ducktape something with GET and POST for the millionth time.
Luckily, soon, GraphQL will be the newest entrant in this space, and will have to contend an influx of superficially-informed people enticed by its promise. It may have a better track record than REST, because a partial implementation of GraphQL will better resemble GraphQL than a partial implementation of REST will resemble REST.
It helps that GraphQL has an actual spec, protocol, and defined schema and is intended to be shipped as a separate microservice that just implements your schema according to the spec.
REST is more "hodge podge of concepts" that you can hack on and pollute and misunderstand at will.
I guess nothing will stop people from making Frankenstein schemas or poorly performing resolvers but at least the consumption is mostly uniform?
Some people would rather take a hodge lodge of concepts over a hodge podge of implementations. HTTP clients have been done to death, GraphQL clients on the other hand...
>REST is not fundamentally inappropriate, it just needs a lot of careful design about domain objects, link relations, and media types. Generally, people are not very good at thoughtful design.
Honestly, this should be a common part of web frameworks by now. It's a travesty that our industry hasn't developed a solid foundation for this kind of thing 16 years after it was published.
The best we've got on this mark is the Waterken server, which is pretty good, but not good enough.
> Have we considered that these REST "anti-patterns" exist because REST is fundamentally inappropriate for what most people are trying to use it for?
Or perhaps people actually don't understand REST, but think they do, thus leading to endless blog articles about "REST levels" and other nonsense.
> What if you can't shoehorn your functionality into the handful of REST verbs?
GET and POST can represent any arbitrary program (they map to the lambda calculus after all). You don't need any more than that, in principle. The other verbs are merely optimizations.
> What ever happened to plain old RPC?
The inescapable failure modes of RPC are exactly what REST addresses.
There's nothing really wrong with RPC in my book, just don't call it REST when it's not. I'd say the bigger issue is that a large number of people implement an RPC variant and call it REST because it's on HTTP and not SOAPy.
Is RPC just ad hoc endpoints? The info on REST is overwhelming, to many different opinions, for a simple SPA do programmers really need a formalized client-server contract? Can one just access server capabilities through ad hoc endpoints and write custom code to fetch the data they need? servers define procedures, and they return data.
I ask because I'm going to start writing my first http api for a small SPA.
It just causes so much busy work. Then busy work leads to bugs, which leads to framework abstractions, which leads to implicit nuance in almost every part of web development.
RPC and client-server contracts, as well as static-typing, is a bloody god send and the whole world will be in a better place once we formalize and accept it (I didn't say standardize I said formalize).
I'll defend REST's utility for simple data retrieval. If I just need a paginated list of comments on a video, being able to quickly hit /video/1093/comments and get that list back is really nice.
More complex use cases, and specifically non-idempotent operations, is where I find REST doesn't hold up as well as RPC.
> If I just need a paginated list of comments on a video, being able to quickly hit /video/1093/comments and get that list back is really nice.
REST isn't about human-readable URLs. The link to the comments should have been part of the representation returned for /video/1093 (typically JSON these days, so a "comments" property of the object).
As ben_jones stated, a client and server need a formalized contract or you're doomed to break things. Whatever you use needs to at a minimum be:
- internally consistent
- sufficiently documented that a developer on either side understands what the other side does
REST is just a set of rules to follow that attempt to avoid some pitfalls and provide a common parlance.
nothing wrong with a good well documented json rpc over http
the main difference is endpoint negotiation vs object state transfer - consider an account representation - if you can withdraw, the link to perform the withdraw operation is there in the server response. if you can't, the link to the withdraw operation is not there. this is how the returned value convey the object state and how it let client explore object operarions.
say, it's the difference between returning an object instead of a struct, and it's also why json alone is not compatible with rest, there's not an agreed schema to identify operations coming along with the data so that a client can actionit - json-ld and hal can, if you reallyhate the idea of xml tho.
As a shorthand, think of REST as about nouns, and RPC about verbs.
/account/1 is REST because the you're looking for an account (noun), the account id is 1, and you're using the HTTP method GET.
/search/hello is RPC because it uses a specific verb (search) to call a remote procedure to search for the 'hello' keyword. You're taking an action for which there is no appropriate HTTP method, so RPC can be used instead of REST.
This doesn't cover 100% of every situation, but it's useful as a quick mnemonic.
That's incorrect. REST has no such restrictions on URLs. URLs can be completely random numbers with no human-discernible meaning.
REST is about architecture, about where state should live, how long it should live, how messages between entities should designate resources/state, all so you can preserve encapsulation and maximal flexibility for service upgrade. Your service is not RESTful if you don't meet these criteria.
RPC has no such restrictions, which means you're free to do everything wrong, which virtually everyone does, and you'll still be doing RPC correctly.
Probably not. If "what this is and how it relates to other things" is determined by looking at the URL path and not the media type (for "what it is") and link relationshops (for how it relates to other things) it's not REST.
And that's the issue. Most engineers don't understand HTTP. Just the amount of people who confuse PUT and POST is pretty high. Getting people to remember that media type exists is hard. Add in the rest, it's just not happening.
But the unicorn "properly designed REST api" is quite nice.
Since i can't trust anyone to do it right though, I'll just use GraphQL because its easier to get people to do right.
Reading over your comments, I'm curious what you would consider to be an API that properly implements REST principles according to the original dissertation.
When people mention RPC in this context, are they talking about a generic concept, or are they referring specifically to SOAP? Because SOAP was always a complex mess, pretending that WSDL files somehow added semantic meaning to data, when it fact it was just a serialization format with excessively verbose data typing and validation of element presence/counts. SOAP made even the smallest projects feel like a bloated nightmare typical of "Enterprise bureaucracy". SOAP is the very reason why people eagerly latched onto JSON and REST the moment it became viable.
For a public facing interface, I haven't really found REST to be lacking. Adherence to REST buys you simplicity and (if kept to the standards) some implicit understandability.
That said, REST is not the right fit for _every_ use case. The same simplicity mentioned as a strength also limits its flexibility. I think this is no more abundantly clear than microservice oriented architectures. More and more these architectures are moving towards different patterns/protocols for various reasons (gRPC comes to mind).
> What if you can't shoehorn your functionality into the handful of REST verbs?
REST doesn't have a handful of verbs, HTTP has a handful of predefined verbs (but supports extensions). REST is an architectural style that does not specify the underlying protocol.
> What if none of the status codes make sense?
Again, that's an HTTP issue not a REST issue. And it's not likely to be a real issue (HTTP status codes may be insufficiently precise—but already support additional data for disambiguation—but I can't imagine a situation where none of them make sense.)
Much as I would like to agree with you, that war was already fought and lost in the early '00s. Port 80/443 were the two ports that couldn't ever be firewalled because web browsing depended on them, so everybody rushed to cram their RPC requests into some kind of HTTP-based protocol.
HTTP != REST though, as the article notes. There are other ways to use port 80/443 that neither violate HTTP nor go full REST - websocket being an (extreme) example.
Even the HTTP monopoly is changing. There are lots of new protocols (HTTP2, QUIC, WebRTC) that work besides firewalls and things like ALPN gives a standardized way to tunnel new protocols over an encrypted connection.
