REST was never about CRUD - <AUTHOR> https://tyk.io/blog/rest-never-crud/ <comment><USER3> I know it's not technically correct, but the conceptual definition I've found useful for myself is that REST is about operating on the HTTP layer instead of building your own layers on top of it. Why create your own custom error protocol when you can use HTTP error codes? Why develop your own caching strategy when you can use HTTP caching? Why create your own authentication mechanism when you can use HTTP authentication over TLS (or client certificates, or etc.)? When the article talks about how REST should be layered, cacheable, and client-agnostic, that's really the core of it to me.

By thinking this way, you can see how REST helps you re-use already-existing infrastructure---proxies, load balancers, caches, etc.---instead of spending time and effort making custom solutions. It also helps provide guidance as to when REST may not be appropriate: can you answer those "why not HTTP?" questions?

I've also found focusing on the resource/noun aspect (beyond considering caching) to be a bit of a "nerd trap"; it's possible to spend a lot of time chasing the perfect, "correct", solution. As the article notes, there's nothing wrong with "verby" URLs as long as you are using HTTP instead of doing your own thing.

<comment><USER4> > Why create your own custom error protocol when you can use HTTP error codes?

Because HTTP error codes are fixed and have well-defined meanings for HTTP that may not map well to your application. Repurposing HTTP error codes conflates your application-specific errors unless it maps to an exact subset of one of the predefined errors.

> Why create your own authentication mechanism when you can use HTTP > authentication over TLS (or client certificates, or etc.)?

Do you have a client cert? I've never encountered any server that supports client certs in my entire 15-year career. Also, TLS is not a part of HTTP and HTTP only supported Basic Auth until fairly recently.

<comment><USER5> _Repurposing HTTP error codes conflates your application-specific errors unless it maps to an exact subset of one of the predefined errors._

...and beware even the errors that match exactly! I've seen multiple systems in the wild that treat 404 as an application-specific error for "content not found". It sounds perfectly reasonable at first, but it puts you one misconfigured reverse proxy away from inadvertently broadcasting to the world that all your content is gone.

This can have data-corrupting effects. If an external system deletes resources via a reliable message queue and treats 404 as a success condition, they run the risk of dropping these messages and creating an inconsistent state. I've seen it happen.

Keep application-specific error messages distinguishable from the 'plumbing'.

<comment><USER6> That seems like a bug with the external system. 4xx means the request needs to be corrected to achieve success. 2xx means success, even if success means "deleted".

If a system treated 5xx responses as successful, you'd consider that a problem with the system's response handling, not a problem with your own communication of state. So why consider abuse of 4xx to be a problem with the communication protocol?

<comment><USER5> The external system didn't define the API; the service did. If you poke around on stackoverflow, you'll find quite a number of answers recommending this pattern. It's a bad idea, but it's not uncommon.

<comment><USER7> Recommending what, that a `DELETE /foo/bar` should return a 404 on success? That's flat-out wrong. It should return a 204 No Content. A subsequent `GET /foo/bar` should return a 404, but presumably the message queue isn't doing a subsequent GET but is inspecting the result of the DELETE.

</comment></comment></comment></comment></comment></comment><comment><USER8> The main problem with REST is Roy Fielding's communication style.

Here's a quote from a 2008 blog post:

 _Apparently, I use words with too many syllables when comparing design trade- offs for network-based applications. I use too many general concepts, like hypertext, to describe REST instead of sticking to a concrete example, like HTML. I am supposed to tell them what they need to do, not how to think of the problem space. A few people even complained that my dissertation is too hard to read. Imagine that!_

Yeah, Roy. It's called being an effective communicator. Effective communicators include stories and concrete examples to help bring the audience along with them, instead of lengthy discussions of abstract concepts. Readers shouldn't have to perform exegesis on your slideshow and blog to get even a vague understanding of what you're trying to get at.

To be clear, any difficulty with REST in practice is a direct result of an underspecified concept without a clearly defined RFC _as it relates to HTTP_. Fielding didn't define anything about REST in terms of HTTP. All of REST, as it relates to HTTP, has been an application of what other people think he meant.

Nowhere in Fielding's 2002 academic paper[0], his 2008 talk at ApacheCon[1], or his blog[2] does Fielding have clear examples or thoughts on the kinds of specific details that Web developers often struggle with.

Fielding, in my estimation, seems principally concerned with three things with regard to REST:

1) Every important resource has its own URI.

2) All interactions against that URI should be stateless and cacheable: all application state that is specific to the user should live on the client (e.g., local storage for browsers), and all shared state should live on the server.

3) Interaction with that URI should be the same regardless of client (browser, mobile app, etc.).

Everything else is left as an exercise for the reader.

[0] [https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm](https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)

[1] [https://www.slideshare.net/royfielding/a-little-rest-and- rel...](https://www.slideshare.net/royfielding/a-little-rest-and-relaxation)

[2] [https://roy.gbiv.com/untangled/category/web- architecture](https://roy.gbiv.com/untangled/category/web-architecture)

<comment><USER9> > It's called being an effective communicator. […] bring the audience along > […] Readers shouldn't have to perform exegesis

He's optimising for communicating with his peers: scientists and academic researchers.

If you find this communication hard to digest, then chances are you are not part of the intended audience. It is then mostly pointless to complain or try to change his wording.

You can buy books from other people who deliberately target developers.

• [https://oreilly.com/catalog/9780596529260](https://oreilly.com/catalog/9780596529260) • [https://oreilly.com/catalog/9780596801694](https://oreilly.com/catalog/9780596801694) • [https://restinpractice.com/](https://restinpractice.com/) • [http://www.designinghypermediaapis.com/](http://www.designinghypermediaapis.com/)

<comment><USER10> That's because they have generations of narrative dialog that is only intended to be used in academia. They use superfluous and oftentimes nonsensical language because they are attempting to create an environment of pseudo intellect, where none exists.

<comment><USER11> Is this parody?

</comment></comment></comment></comment><comment><USER12> Until AJAX happened around 2005, GET and POST were the only verbs you could actually use in a browser. Before then, REST was not a really a thing. It used to be that semantics of HTTP verbs had meaning in the context of e.g. caching and other middleware. But now that everybody uses TLS, having caching proxies acting as middlemen and interpreting http messages is not that common any more.

REST was a nice idea when it got (re)invented about ten years after Fielding's thesis but it left too much open for debate, ambiguity, and nitpicking and quickly degenerated in different opinionated camps trying to retrofit new ideas to the existing practices around http, which mainly boiled down to interesting ways to do RPC.

Before HTTP, people were already long doing RPC using e.g. DCOM, CORBA,RMI, etc. Reinveinting RPC over X has been the fate of pretty much every way we've come up with to make two computers talk to each other.

<comment><USER13> > Before then, REST was not a really a thing.

You only need GET and POST for REST.

> Reinveinting RPC over X has been the fate of pretty much every way we've > come up with to make two computers talk to each other.

REST isn't just RPC, it's RPC with specific constraints to enable caching, scaling, adaptability, and distribution properties that unrestricted RPC alone cannot achieve.

That's why REST is still important today, because RPC is _too flexible_ , and RPC without constraints will inevitably run head first into all of the issues that REST solves for you. Unrestricted RPC libraries then let you "solve" these problems in myriad incompatible ways each with their own problems.

<comment><USER14> > Unrestricted RPC libraries then let you "solve" these problems in myriad > incompatible ways each with their own problems.

I mean, this is exactly the state of REST today. It's not specified well enough to admit general purpose clients (like, for example, GraphQL does) because it's just a "pattern" not a specification.

Because every API has its own way of doing paging, subresource expansion, expressing side-effectful operations, etc it means every API has a corresponding custom-built client.

> Caching

Do these custom clients implement http caching? Not usually.

> Scaling

Arguably, REST is responsible for bringing about the rise of stateless API servers. We should be grateful for the good idea, and not feel compelled to adhere to the other aspects of REST if they don't suit our purposes.

> adaptability

Claims of additional adaptability in REST are usually talking about HATEOAS where each resource defines how it can be interacted with by providing links and semantic metadata etc. I will flat out say it: this doesn't work. Short of building some intelligent agent into your API client, hypertext will never be the engine of application state in any meaningful way. You can't just change the links and have the client magically discover the right thing. Fielding's thesis was talking about the web, where humans are the ones deciding which links to follow. It's a useless concept in API design, and it adds tremendous overhead for zero benefit.

<comment><USER13> > I mean, this is exactly the state of REST today. It's not specified well > enough to admit general purpose clients (like, for example, GraphQL does) > because it's just a "pattern" not a specification.

I don't think that's true. It's very well specified, it's just an _extensible_ specification admitting many possible hypermedia formats. There is no one single hypermedia format to rule them all. Fielding's thesis was about the architecture that allowed the web to scale, and content negotiation and extensible content types are part of that.

> Because every API has its own way of doing paging, subresource expansion, > expressing side-effectful operations, etc it means every API has a > corresponding custom-built client.

This isn't necessary, depending on what you mean by "client". All such operations should be encapsulated as links embedded within a hypermedia format. The client needs only to know the high-level workflow or path to navigate the hypermedia and extract the links it needs.

The hypermedia format itself can change, the links can change, but as long as the path through the hypermedia is preserved, the client works. And there are ways to increase adaptability even further if you don't want to hardcode a path through a set of hypermedia documents, like a flat directory of endpoints (but it's similar to the path, since there must be some shared semantic knowledge about what you're looking for).

> Short of building some intelligent agent into your API client, hypertext > will never be the engine of application state in any meaningful way. You > can't just change the links and have the client magically discover the right > thing.

It sounds like you misunderstand the use of hypermedia for autonomous agents. Throw out HTML and consider a hypermedia format that has only two node types: a named embedded link, and non-link data. An autonomous program can then enumerate all links, or access specific named links it's interested in that may be deeply or shallowly embedded within a web of hypermedia documents.

Most endpoints will probably be shallowly embedded, like with PWAs where the JS simply does a form of RPC with the server. But if you consider more complicated aggregated services, like interacting with someone's bank account where the number of services is large and managed by separate teams (mortgage, stock broker, chequeing, etc.), then it starts to make sense to require deeper embeddings to permit better organization of your teams developing distinct programs on the server-side.

The point being that REST gives you considerably more server-side flexibility to do this.

<comment><USER15> > It sounds like you misunderstand the use of hypermedia for autonomous > agents.

Every time you type hypermedia I want to punch you.

<comment><USER13> Exposure therapy is supposedly effective for anger problems, so let me help you out:

hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia, hypermedia!!

</comment></comment></comment></comment></comment></comment><comment><USER16> The comments here show that there's still much confusion about REST being an architectural STYLE, not an actual architecture.

If you can present your domain as addressable representations of resources and if you can lay out your business logic as changes to these resources, then you could use REST via HTTP to provide access to your service.

Furthermore, if it is important to allow any client to connect to your service and you don't have any control over the clients used, then adopting HATEOAS provides a backward-compatible, future-proof way for client software to work with your service.

If, OTOH, you have full control over the client-side, you can trade-off these abilities for a simpler model (like GraphQL, if you must, or simple RPC over HTTP)

Know what you design for.

Re Caching: Caching in HTTP is _very_ flexible. E-Tags basically give you fine-grained control over how to cache and allow for significant bandwidth/performance improvement. However, in many cases your app will also benefit from an additional cache layer in your persistence layer. Don't confuse them.

</comment><comment><USER17> It seems to me that REST "was never meant to solve web developers problems" at first place and that dissertation wasn't addressed to them. I'm glad we are getting out of REST. Devs need protocols and specifications, not vague architectural ideas that leads to "you're doing it wrong" blog posts. There is no "you're doing it wrong" with GraphQL, or SOAP, or JSON-RPC, you either follow the spec or you don't.

<comment><USER18> Both well-defined protocols and vaguer design/architectural principles have their place. But is it a great idea to take a bunch of such principles and bundle them up under a (confusing) name? Perhaps not.

It seems to me that the initial popularity of "REST" was largely because it wasn't SOAP (and didn't have to be XML), but it was still a name you could give what you were doing that made it sound like you were following some sort of standard.

<comment><USER10> I had zero issues with SOAP. I had zero issues with REST, although I couldn't quite understand the proposed benefit. When people started moving to JSON, I thought, okay, this is literally taking everything that already works and just doing it in an even more complicated way.

It's not hard, but I see very few differences between them. SOAP is easier to read/edit, JSON has less overhead/data, and REST...well, nobody could decide what REST was, so they just made it up or ignored it.

<comment><USER19> > I had zero issues with SOAP.

Just curious, what programming language(s) did you use to provide and/or consume SOAP APIs?

<comment><USER20> I'm not the OP but I've used Python with the _suds_ library to consume SOAP APIs. I haven't had any problems with it other than companies deprecating their SOAP APIs just to reimplement exactly the same thing with JSON.

<comment><USER19> Ah, OK. I don't think suds existed when I first tried to access a SOAP API from Python in 2004. If it did exist, it was certainly obscure.

Perhaps my own experience trying to use SOAP can shed some light on why REST prevailed. In 2004, I tried to use the PayPal mass payment API from a Python application (in the now-defunct Quixote web framework). As I recall, I found one Python SOAP client library, but for some reason, I couldn't use it to access the PayPal API. It was all just so complicated. In desperation, I ended up writing a small service (micro-service?) to access the PayPal API using the official PayPal Java SDK. That service used Jython, because I just couldn't stand Java's verbosity. The main application communicated with the service using XML-RPC.

Compared to SOAP, when I discovered REST, it seemed refreshingly simple, built _for_ the Web rather than awkwardly abusing HTTP as a transport for an over- complicated RPC protocol.

</comment></comment></comment></comment></comment></comment><comment><USER21> After using GraphQL for over a year now I rarely miss the good old REST days. Certainly the declaration of schemas/models in the beginning is maybe more cumbersome compared to REST. But when that is in place is just so easy to work with, no more adding extra field in responses to avoid doing multiple unnecessary queries, just lovely.

When mutating state with GraphQL the suggested approach seems to be to have "action based" endpoints, i.e "publishArticle", which resonates well with me.

<comment><USER22> My biggest issue with GraphQL is the fact that what essentially used to be a database operation has now become a (coordinated) batch API query. So the operation has been split into microservices, then re-joined using a GraphQL interpretation SPoF, all so that client business logic can be encapsulated as a query string, instead of securing that effort as a specialised API endpoint.

Moving flexibility to the client comes with all the inherent risk of that flexibility being available to (in a browser sense) a risky client.

RPC over REST is a solved problem IMO, arguments about REST RPC semantics become ideological after a while.

<comment><USER23> _> RPC over REST is a solved problem_

I'm interested in understanding more about this statement.

Do you mean that all REST RPC libraries are sufficiently developed such that you don't really need to worry about RPC being tricky, or that we all just as a community understand the best strategies and common pitfalls. Or do you mean a specific technology?

Just wondering cause whenever I hear the term RPC as an experience developer I just shudder (-: Thanks!

<comment><USER22> I meant that there are well discussed strategies for handling calls that are RPC-oriented rather than CRUD, not that there are REST libraries that have solved the problem.

Ultimately we find ourselves building 80-90% CRUD operations with edge cases that don't entirely fit with the straightforward RESTful toolset, and in those situations making a call on how to handle it in code is a topic that has by now been more or less discussed to death and becomes a stylistic choice.

REST isn't a protocol, there is definitely interpretation at work.

I was using the term "RPC" to cover topics that are outside the scope of CRUD, "do a thing" as opposed to "manipulate a thing".

<comment><USER23> Thanks!

My own personal take on RPC being solved is that we're all pretty much agreed it's not a good idea unless you absolutely have to!

(I mean RPC in it's more narrow definition as remote, synchronous function calls - e.g. CORBA, SOAP, XML-RPC or the original Unix RPC protocol - for me this is what makes the _resource oriented_ approach of REST a much more appealing approach)

<comment><USER24> > My own personal take on RPC being solved is that we're all pretty much > agreed it's not a good idea unless you absolutely have to!

I'm very much of the opposite opinion — Ideally services are indistinguishable from any other library, and the fact that they're running remotely instead of locally only means there's a couple more (networking-related) error cases to handle. RPC setups like Thrift or gRPC support this way of thinking relatively well, whereas REST's resource/verb paradigm really forces your APIs to have a certain shape.

<comment><USER23> _> Ideally services are indistinguishable from any other library_

I don't mean to be dismissive [0] - but that mindset seems a bit prehistoric to me. We tried CORBA, everybody hated it, and it died!

Indeed, the bible on the topic [1] devotes substantial amounts of time to how to structure your interfaces just so that you avoid issues arising from the discrete system boundaries.

There is a world of difference between issuing an instruction that repositions a program pointer from one position in memory to another, and transferring execution from one compute node to another while _artificially blocking_ execution to _simulate_ a single thread of execution.

(Even, on a single machine with multiple cores this can be a problem - <USER2> to a much more limited degree)

This is why we prefer loosely coupled, message-passing approaches, and resource-oriented ones such as REST. This is why modern languages have "futures" and "promises" (the implication being that we sometimes break promises) and why functional languages are so much in vogue (specifying "what" and leaving a substrate more sympathetic to the underlying architecture to decide "how").

[0] [https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)

[1] [https://www.pearson.com/us/higher- education/program/Henning-...](https://www.pearson.com/us/higher- education/program/Henning-Advanced-CORBA-Programming-with-C/PGM30177.html)

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> Despite the architectural principals, it's named REST--REpresentational State Transfer. It's really hard to twist and contrive a situation in which "REpresentational State" is not CRUD. It can be done, but it's awkward. As soon as you're doing non-CRUD operations, it's really hard to model them as representations of state, and it's sometimes very unpleasant to use APIs where the designers tried too hard to make the peg fit.

</comment><comment><USER26> I disagree with the article and the examples provided.

The author has left out a few key components of REST in their initial distillation. Critically:

 _> REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components._

So given the example from the article:

        POST /articles/{articleId}/approve

This URL does not point to a resource, and the HTTP verb does not describe what action is being taken upon a resource. It's also not using the representation of a resource to capture intent.

It's also worth noting that a GET for the article would return the "status" field and presumably other PUT requests to update the article would either act directly on the article or have other vanity action URLs, making the API more verbose than if everything were done properly.

A RESTful design would be in essence CRUD. It would have a url (/articles/{articleId}) identifying a resource, it would have a representation of a resource that includes a "status" field, and changing the status of the article would involve a PUT request to the URL of the article with the desired change of state.

<comment><USER27> It's a "request to approve an article" resource, even if it hasn't explicitly been modelled that way.

<comment><USER26> By that logic, SOAP is RESTful.

</comment></comment></comment><comment><USER28> REST was never that good to begin with.

(Not even as originally intended, which is very different from RESTful way 99% use it -- originally REST was all about self-reporting and discoverability, which is not used, and irrelevant to most use cases).

Having JSON as the response, and a scheme to address entities, was good. Even using HTTP action semantics was OK (though debatable). But that's far from what REST is about.

Something like JSON-RPC would be a much better for web API needs.

<comment><USER29> That people misused REST is not what made REST "never that good" (in your opinion). In fact, it was this misuse that frustrated Dr. Fielding more than anything else.

<comment><USER30> > That people misused REST is not what made REST "never that good" (in your > opinion).

I used to be partial to that interpretation, but after a few years of looking at it, at what people do and at what's actually valuable, I've come to the conclusion that coldtea is correct: REST as originally intended was not that good for programmatic contexts.

It certainly didn't help that it got quickly buzzwordified as "actually use HTTP properly instead of just shoving your garbage through POST all the time" (the original sin of SOAP or XML-RPC), but even then what makes "REST" work for browsers (which is what the concept was extracted from) is that there is an _intelligent agent_ doing the discovery and driving the interaction.

That's not useful for a programmatic API. You can add a discovery layer to a programmatic API (as e.g. graphql schemas & explorer tools) but requiring programmatic clients to go through such a discovery layer just makes interacting with the API painful for no value.

Traversing a few pages when clicking around in your browser makes sense, doing so from a programmatic client when you could literally just store the correct endpoint and perform your call directly is nonsense: it's inefficient, it's annoying and it's pointlessly verbose. Yet that is essentially what proper rest as described and clarified[0] by Fielding require.

Even the "multiple interpretations" (multiple content types) option is worthless when browsers don't provide the flexibility required to do content negotiation[1] or leverage HTTP verbs beyond GET and POST.

[0] [https://roy.gbiv.com/untangled/2008/rest-apis-must-be- hypert...](https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext- driven)

[1] even in places where they allow actual mimetypes it's as likely as not they'll ignore it e.g. object/@type is a mimetype but no browser I know cares about it, most of them send Accept: ∗/∗ and firefox sends its pagewise/default Accept.

<comment><USER16> > Traversing a few pages when clicking around in your browser makes sense, > doing so from a programmatic client when you could literally just store the > correct endpoint and perform your call directly is nonsense:

That requires implicit knowledge of the 'correct' endpoint. If that endpoint changes or anything in between, you'll have to start versioning your API, which basically tells all existing clients: Sorry, you got to update.

Allowing clients to discover resources is a future-proof way to keep your client libraries compatible and evolve your API without versioning. It is more work for the client and it is not always suitable. But if you intend to design something future-proof (and we are talking about 10+ years), then REST has already proven to be very successful (your latest browser can still browse a web page from 15 years ago...)

<comment><USER30> > That requires implicit knowledge of the 'correct' endpoint. If that endpoint > changes or anything in between, you'll have to start versioning your API, > which basically tells all existing clients: Sorry, you got to update.

In exactly the same way that the "RESTful" version requires implicit knowledge of the content types: that knowledge it not implicit at all, it is specifically and explicitly embedded in the system.

The word you're looking for is _static_.

> Allowing clients to discover resources is a future-proof way to keep your > client libraries compatible and evolve your API without versioning.

That is completely untrue.

> But if you intend to design something future-proof (and we are talking about > 10+ years), then REST has already proven to be very successful (your latest > browser can still browse a web page from 15 years ago…)

Because it has a somewhat intelligent and flexible human driving it and able to adapt in changes to the visited targets. Not so with a programmatic client.

</comment></comment></comment></comment></comment><comment><USER31> Agree. The whole point of rules is that you allowed to break them from time to time.

During development with Rails I struggled a lot, because it was forcing CRUD ideology in places where the custom route could work (and adding it was so painful).

Standardization is fine, but usually it does not solve development issue, it solves management issue, which is common for big orgs not small ones. Especially when it gets on hype or forced by the top management, like it happened numerous times, with latest examples of React, GraphQL or Microservices.

<comment><USER32> Hm, I never found adding custom routes to Rails painful - could you elaborate? Anyway, for smaller use cases I found Sinatra + ActiveRecord a great match.

<comment><USER31> I'll be frank, the latest Rails version I used was Rails 3, and it was like 6 years ago, so I can't really remember details, except that I had to spread logic to like 3 files to make it work. Maybe things changed.

<comment><USER33> No, you didn't have to spread out the logic like that in Rails3. You could do something like

        class AsController < ApplicationController
          def index
          end

          class BsController < ApplicationController
            def create
            end
          end
        end

with routes like

         resources :as do
           resources :bs, controller: "as/bs", only: :create
         end

<comment><USER34> Even that is resourceful routing, just with nested resources. Doing a flat out custom route is even easier:

        class AsController < ApplicationController
          def custom
          end
        end

routes:

        resources :as do
          member { get :custom }
        end

<comment><USER33> Yes, of course.

The whole point of my example was that it is possible to do resourceful routing in a single file without having to resort to using custom routes. I try to avoid custom routes whenever possible - in my experience they lead to pain in the long run, more often than not.

</comment></comment></comment></comment></comment></comment><comment><USER15> My main gripe with REST is that it's totally not future proof. The notion of RPC has been around forever. REST has basically completely replaced that. Http status codes and REST URLs are not future proof. We have already seen superior connection types (web sockets) come (and then basically go) that don't support the notion of URLs and (well they do for a second, but after that the original connection the URL is meaningless for the traffic flow). With Http2 we're seeing the return of lightweight connections (basically similar to websockets but have more graceful re-connection options). But http2 feels like a patch to me. I don't really want to bind the future of Apps to a bunch of URLs. I'd rather tie my app to a client that has a rich semantic set of objects and methods that pull down data, can update data, etc...

When we use REST as our layer to convey the API itself, we really lock ourselves down to a very specific set of URLs and HTTP Status codes. I'd rather have a rich error object thrown, not an HTTP status code that I have to examine.

I've had a pretty strong disdain for REST for the last few years and have been actively finding replacements. The closest I can come up with is Grpc. I'm dying waiting for Google to finish up Grpc-web however. If we continue to tie ourselves to a bunch of server resources by URL we're going to take forever to get off this archaic system that has no long term future.

<comment><USER35> Do you think the web could have been built with RPC instead, and be just as successful?

</comment></comment><comment><USER36> Hmmm, but is REST so often conflated with 'just' CRUD, because that is all people really want from REST, or is it that this perception is so pervasive that people don't know what the potential is. Chicken or Egg? I'm saying Egg, but I'm not saying which that relates to :)

<comment><USER37> CRUD is easy to understand and close to the core of tasks that programmers at large need to do.

Thinking in terms of REST requires that you concern yourself about the full infrastructure. Many programmers i have met simply do not care. Super nice properties such as cacheable and discoverable are outside their domain. Most simply just want remote RPC.

Try convincing a programmer of the benefits of HATEOAS is though. It will be dismissed as too much hassle with no real benefit.

But if you look at it from a data architectural perspective everything just "clicks". Few projects are however approached from that angle.

<comment><USER38> HATEOS can be a weighty concept to get across and it never clicked for me until I read a book on it. I still think there are aspects of it that could be learned easily enough in isolation though. Understanding media types for example allows you to develop some really nice schemes for API versioning. But few people are even willing to learn that and just butcher their URLs instead.

</comment></comment></comment><comment><USER39> The draft BCP56 revision, on the use of HTTP as a substrate, is a nice primer on REST API design

[https://tools.ietf.org/html/draft-ietf-httpbis- bcp56bis](https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis)

</comment><comment><USER40> The way I think of it is that GET, PUT, PATCH and DELETE all deal with data, whereas POST is a call to action.

It is a little unfortunate that we don't have a CREATE verb (distinct from the update-ness of PUT) and we need to use POST for this purpose.

<comment><USER41> That's interesting. Are you saying that you view Posts as verbs/processes which only result in side effects of the underlying system but do not change the state of data? I'm trying to understand what you would consider the domain of actions that would fall under your Post categorization. Batch Jobs, Emailing reports etc.?

<comment><USER40> That's basically right. I view GET/PUT/PATCH/DELETE/CREATE as simple wrappers around SQL commands, with validation and authorization checks.

POST is a call to do something with that data, which might include changing the data. Off the top of my head, logging in, actions with external systems, sending emails.

</comment></comment></comment><comment><USER42> An idea that I've never heard expressed explicitly is how REST is basically distributed OOP. Both REST and OOP lead people to waste their time on unimportant questions.

</comment><comment><USER43> REST is kind of a worthless term at this point because really nobody agrees on what it means.

I'm sure somebody will reply saying "no it clearly means _this_!" or "it obviously means using HTTP how it was supposed to be used" or "those other people just don't understand REST", but the fact is we still have articles - in 2018! - that are trying to explain exactly what "REST" is.

<comment><USER44> If people don't agree with what it means, it's because they aren't spending time reading the actual dissertation. Instead they are kind of glancing over it and depending on others interpretations to create their own. As someone who writes protocol specs, Roy takes great care in being as clear as possible: confusion, inconsistency and misinterpretation are not Worthy Things in protocol implementations. To truly understand REST, you MUST understand HTTP and the rationale behind it.

<comment><USER45> Perhaps he should have written a specification for REST.

</comment></comment></comment><comment><USER46> I don't think anyone ever says RESTful services must be CRUD based, what they say is non-crud operations are hard to model in a RESTful service.

</comment><comment><USER47> REST as seen in HTTP has always been about resources (identified by URLs), representations thereof that take the form of a particular mediatype (selected explicitly or by content negotiation), and hyperlinks (with targets and rels).

When resources are obvious nouns already present in the backend's data model, this maps well to CRUD. The problem comes when trying to describe complex mutations, because to most people, this feels wrong, instilled by years of Dos and Don'ts of half-baked lessons about Object Oriented design.

In all this time between when Roy's thesis was rediscovered to promote an architectural style and when the trendiness of REST has finally run its course, there were far too many posts complaining about deployments missing hyperlinks (when usually, the API was externally documented, URLs templated, and its clients hardcoded, making many usecases of embedded hyperlinks moot), and not enough to reassure flummoxed designers that naming resources after verbal nouns or deverbal nouns is perfectly fine. Oops.

</comment><comment><USER48> The useful/valuable part of what came to be called "REST" (very little of which is found in the dissertation, it's an accident of terminology which has lead a lot of people astray) is all about CRUD, because CRUD is the only thing that makes sense to do with a generic "resource".

<comment><USER49> POST is used for way, way, way more than any CRUD operation.

<comment><USER48> Indeed it is, but at that point it's not "REST".

<comment><USER49> Why wouldn't it be?

<comment><USER48> The HTTP verb isn't reflecting what's happening, and likely some important considerations aren't being represented as entities.

<comment><USER49> The description of the POST method is very generic; one of its functions detailed in the HTTP spec is:

          - Providing a block of data, such as the result of submitting a
            form, to a data-handling process;

Which fits with much more than mere CRUD. And it's specifically written that it doesn't have to result in the creation of a new URI-addressable resource.

(Also, REST isn't HTTP, you can comply with the former even if you're violating the latter, and vice-versa)

<comment><USER48> > Also, REST isn't HTTP, you can comply with the former even if you're > violating the latter, and vice-versa

Exactly. Complex processing via POSTs instead of distinct URI-addressable resources is HTTP-compliant but not REST-compliant.

<comment><USER49> I just don't see how it violates any of the REST constraints.

<comment><USER26> I think of REST imposing a certain grammar that HTTP alone doesn't necessarily require. Remember, REST is resource-driven.

\- HTTP verbs are like normal verbs. They represent an action.

\- URLs represent the location of a resource or collection of resources.

\- Resources are like nouns. They represent what is being acted upon.

As soon as you start assigning different actions based on different URLs, the HTTP verb no longer actually represents an action and the URL no longer points to a resource.

<comment><USER49> If you make an analogy, and then the analogy breaks, I'm not sure that shows the flaw is in the original concept.

A RESTful architecture needs an Uniform Interface, yes, but their it's doesn't have to be an "action" or anything specific. POST has a definition, and everyone handling the requests can rely on it. That fulfills the constraint.

<comment><USER26> It's not really an analogy, though. If you have a POST request triggering some random sequence of actions, what's the resource? What representation of state is being transferred?

It's not REST, it's just HTTP.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER50> The author proposes:

        POST /articles/{articleId}/submit
        POST /articles/{articleId}/approve
        POST /articles/{articleId}/decline
        POST /articles/{articleId}/publish

I find this troublesome because the URL path component then includes a verb, an _action_ , so there are two verbs in the same sentence!

This can be adjusted to:

        POST /articles/{articleId}/submitted
        POST /articles/{articleId}/approved
        POST /articles/{articleId}/declined
        POST /articles/{articleId}/published

Now the URLs really represent _resources_ on which HTTP verbs operate, and you can readily guess what GET (if needed/applicable) on each resource would give you.

There is some cognitive dissonance introduced by the inconsistency of abstraction levels between the former "RPC style" (where HTTP verbs are mere actuators† and the intent is in the URL and/or in the payload), and the latter "REST style" (where verbs carry intent acted upon resources).

EDIT: I do not advocate for one over the other, merely that an API should be consistent overall and not mix both.

† They are used as pure HTTP feature control (like caching) and do not carry application-level semantics.

</comment><comment><USER51> I'd like to implement such and API, but I feel often time its not that we don't want to design an API that way, but that we fail to successfully implement one.

I'd like to hear about guidelines, like for that transaction workflow example, how would you implement this? What would be your data model?

</comment><comment><USER52> I don't agree with the article (to me REST started about CRUD, and obviously got overloaded with time), but that's not what I need to comment.

That font in the titles could have been gorgeous, but that upper case "D" is offendingly bad.

<comment><USER36> Ouch! Take your point, but don't you think the feels you get from the lower case "about" in the title makes up for any failing in the "D"?

</comment></comment><comment><USER53> I've been a long time fan of what this article is saying - but I didn't know it was a thing. Now if I ever run into CRUDdy teams, I have something to share with them :)

</comment><comment><USER54> Only one thing about this article i have to say is that its posted on TERRIBLY designed page... Half of the screen black, align to the right and no "reading view".

<comment><USER36> Harsh but fair!? We're listening, feedback has been passed to the team who look after [https://tyk.io/](https://tyk.io/).

</comment></comment><comment><USER55> The same old story with anything called "architecture patterns", you can look at them from different angles and each time you will have a new interpretation.

</comment><comment><USER56> Half the page is a calendar widget?! This is the worst layout I've seen in a long time.

<comment><USER36> Harsh criticism Johnny! But we'll take it on board, feedback has been passed to the [https://tyk.io/](https://tyk.io/) team, there is certainly an opportunity to adjust proportions here. As a matter of interest, which blog/article page layout do you really rate?

<comment><USER56> I think I was that emphatic because I couldn't believe anyone would want to exhibit such an obviously flawed design in public until it was fixed. I'm still confused how this would make the light of day, but I guess esthetics and usability are something learned perhaps over time?

</comment></comment></comment><comment><USER57> This is an oft revisited topic, and it might be worthwhile to cite a few paragraphs from Dr Fielding in order to support and expand upon the submitted article.

"Search my dissertation and you won't find any mention of CRUD or POST." [0]

> For example, some APIs may need to support actions such as submit, approve, > and decline. With our somewhat limited action verbs in HTTP, how can we add > this to our API?

By representing the difference in states. Or otherwise. The communication medium is not the API. ("A REST API should not be dependent on any single communication protocol, though its successful mapping to a given protocol may be dependent on the availability of metadata, choice of methods, etc. " [1])

> POST /articles/{articleId}/publish , POST /articles/{articleId}/submit , ... > etc.

A few years ago I was zealously advocating against representing actions in URIs, and using a generic /actions [sub]resource, but this actually makes it simpler to represent the available actions to the client. And sure, this can be thought of as REST via the code-on-demand part of the architecture. The server points to a script (it doesn't have to be JS, but the media type must be defined in the REST API), that can understand the available actions from the state representation, and construct the necessary representations for the desired actions. (So in a HTTP API, the JS interprets the JSON and knows how to put together POST requests to modify the resources, without the actions having been reified and URI-fied in the JSON.)

> The workflow our API supports is more explicit, [...]

Sure, that's pragmatic, but after much gnashing of teeth and scratching of heads, REST is about presenting options to the client by offering various media types (content-types), and letting the client request the best representation, and not really about a fixed ACL neither about fixed flow.

From [1] again: "A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext- enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of- band information is driving interaction instead of hypertext.]"

[0] [https://roy.gbiv.com/untangled/2009/it-is-okay-to-use- post](https://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post)

[1] [https://roy.gbiv.com/untangled/2008/rest-apis-must-be- hypert...](https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext- driven)

<comment><USER58> > "A REST API should spend almost all of its descriptive effort in defining > the media type(s) used for representing resources and driving application > state, or in defining extended relation names and/or hypertext-enabled mark- > up for existing standard media types. Any effort spent describing what > methods to use on what URIs of interest should be entirely defined within > the scope of the processing rules for a media type (and, in most cases, > already defined by existing media types).

Arguably this is the problem: what Fielding is describing here has a well- known name: Object Oriented Analysis and Design. It's not at all clear why a new formalization was needed when we already have Objects. Resources have URIs, Objects have memory addresses. Resources have representations that are defined by content media types, Objects have behavior that are defined by -- types.

> POST /articles/{articleId}/publish , POST /articles/{articleId}/submit , ... > etc.

Good ol' OOAD can avoid nonsense like this. It's immediately clear that the Resources identified by these URIs aren't real objects. If you want to talk Published Articles vs Submitted Articles you would introduce new types and new repositories.

The only way this makes any sense is:

POST /articles/published/ POST /articles/submitted/

Only now does 'GET /articles/published/{articleID}' make sense and we might think about what that content media type looks like vs submitted articles.

<comment><USER57> It looks like this is a case of the stereotypical academization. Fielding looked at the Web, and abstracted it, and calls it REST Architecture.

And of course, the problem is that nobody sits down to just do a quick World Wide Web API for an app, or an internal corporate business-as-usual thingie. In fact since the original hypertext project at CERN no one every did it. We still use the same Web, incrementally transformed into what it is today, but still the same HTML, same Content-Types, and HTML1.0-like markup. All eaten and excreted by JavaScript of course, but that's a prime example of something incremental, and not exactly thought out.

Moreover, there's not much to say about media types driving interaction, because 99.9% of the Web is GET GET GET. And OPTIONS (due CORS) is driven by out-of-band conventions (defined in the Fetch and the amended XHR APIs, but not much to do with media types - but of course, CORS is more about fixing the leaky encapsulations of the communications interface/layer, not about the content [the high level state being transferred]).

<comment><USER59> > Fielding looked at the Web, and abstracted it, and calls it REST > Architecture.

yeah the perfect rest protocol is the web and the perfect rest clients are the humans that navigate the action represented on the hypermedia.

that said, there's some value to be had in discoverability, even if rest grossly gloss over how to discover parameters for the action that the state holds.

<comment><USER30> > that said, there's some value to be had in discoverability, even if rest > grossly gloss over how to discover parameters for the action that the state > holds.

There absolutely is and API systems like graphql have taken that to heart (playing with a graphql explorer is delightful).

But forcing all programmatic interactions through a "discoverability" layer is not useful, yet that's essentially what REST (as originally formalised) mandates.

</comment></comment></comment></comment></comment><comment><USER29> Many years ago, Dr. Fielding would visit a forum or two and offer answers to questions about REST. I had a number of my questions answered directly by him which helped me through the years to discover how many people have no clue about what REST is and how to use it but wave the REST flag as if they did-- and they don't.

I believe Roy quit visiting forums for those reasons; a frustration dealing with all that.

<comment><USER28> Words are not defined by their creators, they are defined by their usage.

Those people indeed know what REST is -- in fact, they define what REST is. When we talk about REST, we talk about how people use it.

They might not know what "REST as defined by Dr. Fielding is" but that's not really relevant to them or to the industry at large.

<comment><USER60> "use", not "usage". </joke>

<comment><USER28> Not according to my dictionary:

use: the action of using something or the state of being used for a purpose.

usage: the action of using something or the fact of being used: a survey of water usage

<comment><USER61> Words are not defined by their creators, they are defined by their use.

Those people indeed know what USAGE is -- in fact, they define what USAGE is. When we talk about USAGE, we talk about how people use it.

They might not know what "USAGE as defined by coldtea is" but that's not really relevant to them or to the population at large.

:-)</comment></comment></comment></comment></comment>


Violet Blue's List of The Top Ten Sexy Geeks 2008 - <AUTHOR> http://laughingsquid.com/violet-blue%E2%80%99s-list-of-the-top-ten-sexy-geeks-2008/

<comment><USER2> Are people who are social media, marketing, or productivity experts really considered "geeks" by the geek community? For example, Tim Ferriss is at #4, but is he considered a "geek"?

<comment><USER3> It's better than Wired's list, which was mostly actresses who play geeks and talking-head hosts of video podcasts.</comment></comment>


Building a desktop application with Electron - <AUTHOR> https://medium.com/@bojzi/building-a-desktop-application-with-electron-204203eeb658 <comment><USER2> The problem with this is that users have to download a binary of over 40mb just to run a "hello world" app. The whole thing has to embed all of node.js plus all of a browser. I miss the days where to download a crazy complicated app required only 200kb - like uTorrent for example. I know space and bandwidth have gotten cheaper, but there's something about creating an app that only carries the bare essentials that calls for quality.

<comment><USER3> The problem is more about using webtechs for the UI than the size of the binary. There is a reason why people aren't massively moving from text editors such as Sublime Text to Webtech based editors like atom : performances. But everything is cyclical, we are just still in the "you can do everything with html and js" era. Go,Nim,Rust,Crystal and others are on their way in. They are statically typed, multithreaded, easier than C and C++ , compiled and can be linked to Gtk,Qt and other multiplateform UI toolkits. Javascript everywhere even where it doesn't make sense is on its way out.

<comment><USER4> The reason for all this, despite the "man, js is terrible / slow" argument, is just that there are a lot of web-developers out there, with a big bag of tools, frameworks and "to-js"-compilers, wanting to create something, but _just don 't have the time_ to learn a complete new cross-plattform infrastructure, which JUST DOESNT REALLY EXISTS. You have to ponder if its just worth the efforts to build something native or go fast(in terms of development-time) and cross-plattform with sometimes reasonable trade-offs.

If there will be a "mostly unified" UI-Framework for android,ios,win10-mobile,windows, osx and linux for any compiled language, i will be the first to jump onto that waggon...

<comment><USER5> There has got to be a middle ground where the backend of such application is build on something that is faster and safer while the front end adopts the web languages (HTML/CSS/JS). Specially for application that are not graphically intensive by default.

</comment></comment></comment></comment><comment><USER6> This is a good introduction. I recently started playing with Electron after being frustrated with trying to get NW.js to install gracefully ( _without_ having to edit a binary first).

I'm currently working with node-sodium on a simple E2E encrypted chat app in Electron (for fun only! I'm not reinventing Cryptocat).

<comment><AUTHOR> Yeah, that's what put me off of NW.js too. The prebuilt Electron binaries, electron-packager and electron-builder are too good to pass up. That also sounds like a sweet project to learn the ins and outs of Node because you can hack away at a chat app for weeks adding cool features.

</comment></comment><comment><USER7> I made a simple demo/ starter app in Electron right around the time when the project was renamed from Atom-Shell. [https://github.com/thom-nic/electron- demo/](https://github.com/thom-nic/electron-demo/)

I'm sure documentation has improved since then but at the time it was very inconsistent. Also props to the author of this article for doing a clever app that doesn't look like it's a page in a browser window - I wasn't that clever ;)

<comment><AUTHOR> That looks pretty cool and I love that there's a ready made gulp file for most of the common tasks. :)

</comment></comment><comment><USER8> Still seems like there should be an approach like this to build mobile and desktop? TideKit (split off from Appcelerator Titanium) was giving it a shot but I think might have dissolved.

<comment><USER9> We are doing some larger scale desktop stuff with Ionic right now, and someone from the community wrote about doing something similar: [http://www.raymondcamden.com/2015/07/23/some-initial- thought...](http://www.raymondcamden.com/2015/07/23/some-initial-thoughts-on- building-desktop-apps-with-ionic-and-electron)

It's interesting. Not sure where we'll take it, but I love the idea of one code base running everywhere, including desktop.

<comment><USER8> The "one" code base is sorta interesting but I really like the one, relatively easy programming model.

</comment></comment></comment><comment><USER10> great great turotial, Coming from php I've learned a lot in minutes.

</comment><comment><USER11> _facepalm_</comment>


World War I soldier's room untouched for nearly a century - <AUTHOR> http://www.washingtonpost.com/news/morning-mix/wp/2014/12/29/world-war-i-soldiers-room-untouched-for-almost-100-years/

<comment><USER2> Previous discussion - [https://news.ycombinator.com/item?id=8456008](https://news.ycombinator.com/item?id=8456008)

<comment><AUTHOR> Thanks, I'd not seen it back then.

</comment></comment><comment><AUTHOR> Other than the obvious tribute to the sadness of his parents, the thing I took away from the article is how spare the room was. As an officer, one would presume he was from the upper classes, and yet his room is very plain. We really do live in the lap of luxury nowadays!</comment>


MongoDB 2.8 – New WiredTiger Storage Engine Adds Compression (with Graphs) - <AUTHOR> http://comerford.cc/wordpress/2014/11/12/mongodb-2-8-new-wiredtiger-storage-engine-adds-compression/

<comment><AUTHOR> Follow up post which tests a patch and shows significant improvements and backs up the original premise:

[http://comerford.cc/wordpress/2014/11/17/mongodb-2-8-improvi...](http://comerford.cc/wordpress/2014/11/17/mongodb-2-8-improving- wiredtiger-performance/)</comment>


"The Internet Hall Of Fame" - <AUTHOR> http://techcrunch.com/2014/06/13/internet-hall-of-fame/ The World Startup Report & Startup Genome release 'The Internet Hall Of Fame" with data from 50 countries <comment><USER2> Andrius with World Startup Report here. Happy to take any questions about the report. Also - the raw data can be found here [https://docs.google.com/spreadsheets/d/1XrExbBV6810NANr_jFOX...](https://docs.google.com/spreadsheets/d/1XrExbBV6810NANr_jFOXNEsQkLGm_Qs6TQb5X_OfXGc/edit)

</comment><comment><AUTHOR> \+ Shane with Startup Genome. Our curators helped with some of the data collection. Happy to answer Qs about the report but also want to hear any ideas for future cross-country reports we can do. Any ideas?

</comment><comment><USER3> How did you collect the data?

<comment><USER2> Data comes from online sources, stock market data, company information, and people working within startups in each place.</comment></comment>


University of California Sells $200M Fossil Fuel Holdings - <AUTHOR> http://www.bloomberg.com/news/articles/2015-09-10/university-of-california-sells-200-million-fossil-fuel-holdings <comment><USER2> What should be taken from this is when a university has more money than GDP of 2/3rd of the nations in the world (individually ofc) something has really went wrong.

Not saying the educational institutions shouldn't have money but when you have more assets than the GDP of Luxembourg you maybe should stop charging 25K a year...</comment>


The cost of small modules - <AUTHOR> https://nolanlawson.com/2016/08/15/the-cost-of-small-modules/ <comment><USER2> The performance data is great to have, but gives me more reassurance than concern. Between browserify and closure compiler, we're looking at a 15ms to 40ms difference until we get well over 1000 modules. Even complex SPA apps I've written come in nowhere near 1000 modules, a few hundred at most.

Interestingly the performance difference between mobile and desktop on a fast connection was negligible.

Browserify and webpack are really developer friendly, so it's an easy business decision to sacrifice 15ms in overall load time and instead pre-hydrate the first page or use another trick to provide responsiveness while modules load.

I think front end dev process can still use plenty of improvement, but my primary takeaway here is to be conscious of the tools being used and the dependencies they import. It doesn't need to be a complex issue.

<comment><USER3> A few hundred modules? Could you talk more about that?

<comment><USER4> "Modules" refers to individual source files, not npm packages. A single npm package can contain many source files, each of which is a separate CommonJS module.

Most npm modules are small, so I'd expect in the average case that the majority of modules are actually your own app code.

</comment></comment></comment><comment><USER5> This is really interesting. I think there's a lot of room for improvement in the tooling, though, and my gut instinct is that theoretically, Browserified/Webpacked code can be as fast if not faster than other compiled methods. The reason for this is that the bundler has more structural information about the code it's working with. More information theoretically equals more opportunities for optimization.

Not saying those optimizations will be easy. I'm marginally familiar with both the Browserify and Webpack codebases, and I certainly wouldn't want to be the one to implement any of this. But, assuming all the benchmarks in this post prove to be reproducible (and I'm expecting them to be), I hope that those more familiar with the tooling will be able to build a world where we get to have both the user experience and developer experience we want.

<comment><USER4> > the bundler has more structural information about the code it's working with

For CommonJS modules this is only true to a very limited extent as the export binding process can run arbitrary code which can't be analysed (it's Turing complete).

ES6 modules on the other hand are static and can be extensively analysed without difficulty. This makes, for example tree-shaking pretty easy. Rollup is an ES6 module builder which is doing this already. The future's bright.

</comment></comment><comment><USER6> In haxe with static type system, dce and inling function we haven't this problem if we use haxe libraries. The libraries can be really big or little, but dce inject only classes and methods used. Same thing can be made with scala.js and clojure using google closure.

</comment><comment><USER7> I've been using rollupify in my projects for a few months now with no issues, but I didnt know it didnt work on npm modules. I would be interesting to see benchmarks of rollupify vs rollup on ots own to see if its worth changing bundlers.

<comment><USER8> (rollupify author here.) It works if you configure Rollup to use a plugin like [https://github.com/rollup/rollup-plugin-node- resolve](https://github.com/rollup/rollup-plugin-node-resolve), and it works best if the third-party packages also expose jsnext:main or the new "module" field in package.json.

Overall though there are still lots of edge cases that aren't well-covered without plugins (such as globals like process.nextTick etc.). Some details here: [https://github.com/rollup/rollup/issues/552](https://github.com/rollup/rollup/issues/552)

</comment></comment><comment><USER9> In pure functional programming, which is most of what I do, there are zillions of "small modules" and everything seems to work just fine...

<comment><USER10> The problem isn't (necessarily) small modules, it's the _dynamics_ of the Common.js (and similar) module systems. By conflating fully general, extensible, dynamically typed objects with both namespaces and modules, the semantics can't be constrained enough to perform certain kinds of both intra- and inter-module optimizations at compile time.

By contrast, the Google Closure compiler's module system (also for JavaScript) does not suffer from this problem, but in tradeoff, disallows many types of runtime metaprogramming, such as merging modules with Object.assign or similar.

</comment></comment><comment><USER11> Now lets see some charts about build times.

</comment><comment><USER12> i think its a common misconseption that code dissappears once you brake it down into modules.

</comment><comment><USER13> Wait till people figure out the cost of managing and coordinating all these microservices...

<comment><USER14> Yep. And the cycle will continue...

Which makes me wonder how one decides where and when to get off the treadmill. Sadly I think it's a factor of age as much as technical merit. I hit the point where I felt that we'd reached perfection with Postgres to do relational plus the ability to go schemaless when it made sense, a nice MVC framework in a sane language such as Django or Rails, a smattering of client side magic where required using good old jQuery and finally something like PJAX or Turbolinks to give you that satisfying 'no page reload' feeling.

Get off my lawn...

<comment><USER15> I saw a brilliant graphic a while back, but can't find it now. It shows 4 stages of development methodology in a big loop. It goes...

      Spaghetti code -> MVC -> DI -> advanced framework

Personally, I embrace the suck and get off the roundabout at 'spaghetti code'. Define things as straight forward as I can as a sequence of instructions and abstract as little and as usefully as possible. Things that get repeated go into a function. Whole systems that get used more than once go into their own module. If I find myself copying and pasting between projects, it becomes its own library. If a library I'm using doesn't exactly fit my use case, I put it away and write a new one from scratch.

That last one was especially hard for me. It's so tempting to spend hours or even days on google searching for just the right library somebody else wrote that will fit your use case. Don't do it. Write it yourself. It'll be quicker and you'll learn more.

<comment><USER16> "...It'll be quicker and you'll learn more...." \- Not to be snarky, but yeah - it'll be quicker to write up front, but you'll learn more...from finding and debugging all the edge cases the library authors may have already dealt with. And there goes the time you "saved" up front.

<comment><USER15> "may" being the key word here. The library you choose "may" have already dealt with those edge cases. Or you may spend hours or days debugging the god damned thing. In my experience in javascript development, the latter is far more likely.

</comment></comment></comment></comment></comment><comment><USER17> Interesting benchmarks, in particolar they invite to try rollup.</comment>


Incredible events at Browserling last week - <AUTHOR> http://www.catonmat.net/blog/incredible-events-at-browserling/ <comment><AUTHOR> This emphasizes that there are still a whole lot of people eager to get online. "The next billion".</comment>


On the Waste Isolation Pilot Plant 10,000 Year Marker System - <AUTHOR> https://99percentinvisible.org/episode/ten-thousand-years/ <comment><USER2> This issue seems to result in heavy bikeshedding.

Here's an existing marker for a nuclear burial site.[1] This is where the SL-1 reactor blew up in the 1960s. (SL-1 was an experimental reactor at the Idaho Reactor Test Station, in the middle of nowhere for good reasons.)

Realistically, sites like that require a major mining effort to get into, and any society capable of that probably will know about radioactivity, along with all the other risks of mining.

[1] [https://en.wikipedia.org/wiki/SL-1#/media/File:SL-1Burial.jp...](https://en.wikipedia.org/wiki/SL-1#/media/File:SL-1Burial.jpg)

<comment><USER3> That sign depends on the circle-cross symbol, nuclear warning symbol, and bottles all being meaningful 10,000 years from now. We have trouble deciphering symbols from less than half thst long ago. Your point about mining could be true, unless some geological event makes it more accessible.

</comment></comment><comment><USER4> [https://urbigenous.net/library/WIPP/](https://urbigenous.net/library/WIPP/)

 _This place is not a place of honor.

No highly esteemed deed is commemorated here.

Nothing valued is here.

This place is a message and part of a system of messages.

Pay attention to it!

Sending this message was important to us.

We considered ourselves to be a powerful culture.

This place is best shunned and left uninhabited._

</comment><comment><USER5> Direct link to Sandia PDF:

[http://prod.sandia.gov/techlib/access- control.cgi/1992/92138...](http://prod.sandia.gov/techlib/access- control.cgi/1992/921382.pdf)

The document in question is numbered Sandia 92-1382

</comment><comment><USER6> WIPP is one of HN's all time most popular reposts:

[https://hn.algolia.com/?query=wipp&sort=byPopularity&prefix=...](https://hn.algolia.com/?query=wipp&sort=byPopularity&prefix=false&page=0&dateRange=all&type=story)

Lots of past comments to read.

280 comments at [https://news.ycombinator.com/item?id=11851871](https://news.ycombinator.com/item?id=11851871)

</comment><comment><USER7> I've read several articles about the 10,000 year marker system, but, this is the first time I recall "Ray Cats" as a potential solution.

<comment><USER8> If the engineered changing-color genes don't confer any evolutionary advantage, won't the cats' descendants quickly lose them?

<comment><USER9> Only if they confer an evolutionary _disadvantage_ \- for example, a higher cancer rate. Otherwise it will just be there as so much genetic baggage.</comment></comment></comment>


Equifax is extending year of free credit reporting - <AUTHOR> https://www.trustedid.com/premier/faqs_notification_extend.php <comment> java-man how are they still in business?</comment>


Ask HN: What is the state of C++ vs. Rust? (2019 edition) - <AUTHOR> Previous discussion: https://news.ycombinator.com/item?id=12744317<p>How have things evolved since then? <comment><USER2> Rust is not for common project. Rust is only for safety.

I just recommend modern C++ and golang

</comment><comment><USER3> C++ has come a long way, and C++20 is extremely promising. Modern C++ can be as safe as Rust.</comment>


Building a Ray-Tracing 3D Renderer from Scratch Over a Weekend - <AUTHOR> http://www.superjer.com/pixelmachine/

<comment><USER2> nice, very impressive.

</comment><comment><USER3> This guy is a real hacker!</comment>


War by any means: The story of DARPA - <AUTHOR> https://www.newscientist.com/article/2125337-war-by-any-means-the-story-of-darpa/ <comment><USER2> I've always hated the argument that said "but look at how much technology has come out of the military [with all of those tens of trillions of dollars invested in it over the span of a few decades]!"

Yeah, and imagine how many orders of magnitude more it would've come out if say NASA had gotten that money, or some other government agency with specific goals of doing R&D for the consumer market, like say investing $200-$300 billion a year to create better batteries, LCDs, processors, VR tech, and so on.

The military has spent much of that money on _buying weapons_ , then a large chunk of it on _researching weapons_ , and whatever consumer technology came out of _that_ was incidental. It only seems we've gotten "so much", because the investments were so huge, so even if only 0.1% of the military tech rubbed off on the consumer market, it still seems like a lot.

A good example of this is how the U.S. government has largely refused to invest in anything other than radioactive nuclear reactors, preferring nuclear reactors based on uranium over say thorium, because it could also use the uranium to build weapons. Perhaps people wouldn't be so against nuclear reactors now if most of them were using thorium. And maybe we'd even have nuclear-powered rockets by now, making those Mars trips much shorter.

<comment><USER3> > I've always hated the argument that said "but look at how much technology > has come out of the military [with all of those tens of trillions of dollars > invested in it over the span of a few decades]!"

> Yeah, and imagine how many orders of magnitude more it would've come out if > say NASA had gotten that money

That _exact_ same argument applies to giving money to NASA. Sure, it has spun off some useful technology (no, not just Tang, space pens & freeze-dried ice cream), but while we see that technology, we _don 't_ see the innovations which _could_ have been developed with that money elsewhere. There's no reason to think that the state can pick innovative winners any better than it can pick economic winners.

The reason to spend money on the military is national defense, period — not some amorphous 'oh, we'll get some cool tech out of it too!' The same applies to NASA or any other government agency.

<comment><USER4> NASA has developed a _lot_ of technology, but I somewhat agree. Silicon Valley get's a great reputation, but has fewer real successes than you might think. The basic problem is your 1000th rocket is not any more innovative than your 1000th dating app.

Which is the core issue, private industry hates investing in long term research and it has a small problem space. The government funding got self driving cars close enough to production ready that companies are willing to finish the process. But, no company was trying to build a freeway capable self driving car 30 years ago and then publish their results.

</comment></comment></comment><comment><USER5> > And there is an eye-popping account of the only underground nuclear test > ever done in Mississippi.

Wow. Never know that.

[http://mshistorynow.mdah.state.ms.us/articles/293/nuclear- bl...](http://mshistorynow.mdah.state.ms.us/articles/293/nuclear-blasts-in- mississippi)

<comment><USER6> I did not know that either. I can't imagine the rationale for testing in a populated area. Even if the perceived risk was low, the additional cost of testing in a desolate area can't have been that substantial.

<comment><USER5> Peaceful uses of nuclear devices was a thing in the 60s.

</comment></comment></comment><comment><USER7> I can only wonder what DARPA are doing currently behind all the secrecy, assuming whatever disclosed in the book is, let say, 20 years back technology.

p/s: there doesn't seems to be a lot of red-tape in approving whatever the 'researchers' wants to do, at least in the past

<comment><USER8> You can actually see what DARPA wants to do by looking at their business solicitations. The US government makes a giant wishlist available as a website for businesses to browse and submit proposals for. The last few years, the big ticket item for most organizations is some kind of artificial intelligence that can intelligently process mountains of data. DARPA wants one, too. But they're also into some kinkier stuff.

<comment><USER9> As one related example, DARPA is interested in "explainable artificial intelligence". Essentially machine learning where the decision making process and intermediary steps are less opaque to humans.

[http://www.darpa.mil/program/explainable-artificial- intellig...](http://www.darpa.mil/program/explainable-artificial-intelligence)

<comment><USER10> What's funny is Google's actually doing a fair bit of this already with the TensorFlow playground, flow-based programming, Distill, etc. DoD will shower money on researchers, but those same researchers will do the work for Google for stock, a decent salary, and access to interesting problems that don't involve killing people.

<comment><USER11> That's not what "explainable ML is".

That project is about explaining how (say) a given classifier came to a decision on a given set of data. This is fairly easy on a tree-based classifier, but on a deep neural network is extremely difficult.

The most impressive piece of work I'm aware of in this area is LIME, from _"Why Should I Trust You?" Explaining the Predictions of Any Classifier_ [1]

The acknowledgement section of that paper read, in part:

 _This work was supported in part by ONR awards #W911NF-13-1-0246 and #N00014-13-1-0023, and in part by TerraSwarm, one of six centers of STARnet, a Semiconductor Research Corporation program sponsored by MARCO and DARPA._

Today I saw ELI5[2], which encapsulates LIME and a number of other similar tools.

[1] [https://arxiv.org/pdf/1602.04938.pdf](https://arxiv.org/pdf/1602.04938.pdf)

[2] [http://eli5.readthedocs.io/en/latest/](http://eli5.readthedocs.io/en/latest/)

</comment></comment></comment></comment></comment><comment><USER12> DARPA exists because the military wants wizards working for it. The military often describes what units do as various parts of the spear, "tip of the spear" etc. Science is capable of not only producing a better spear, but changing the paradigm entirely.

In not even the most rabid fever dreams of generals would an army without science be capable of even a fraction of the capabilities of an army with.

\- Armies fight on their stomachs - so science produced stay good food that lasts under any condition for _years_ with special storage, comes in a variety of menus and even provides for hot menus without the use of fire [1]

\- Soldiers need better tactical capabilities - so science let them see in the dark [2], become stronger [3], gave them perfect aim [4], gave them god-like ability to peel back the fog of war [5] and made them nearly indestructible [6][7]

\- Generals needed more powerful options - so science created nuclear weapons [8], the ability to see from atop Mount Olympus[9][10], physics bending intelligence collection capabilities[11], ships that stay beneath the sea for months [12], combat aircraft that don't put the pilots at risk[13], and tanks that can survive in any condition [14], and soon the ability to harness energy to knock enemy munitions from the sky[15] or to through matter at many times the speed of sound using invisible forces[16]

This combat magnification extends to logistics, information processing, chemical warfare (and defense), biological warfare (and defense), intelligence collection and so on.

An equivalent force from the 19th century would be turned into pulp by a force from today. And our forces probably wouldn't even be in harms way during the major exchange.

Significantly advanced technology is indistinguishable from magic, and scientists and engineers who develop it are the wizards of modern times. DARPA merely tries to give wizards a place to hone their craft. Sometimes their work leaks out in the public and we're touched by this magic to make the internet, or use GPS, safer food, make medicine more life saving and so on. Sometimes we're on the receiving end of dark magic and our cities get turned to dust.

1 - [https://en.wikipedia.org/wiki/Meal,_Ready-to- Eat](https://en.wikipedia.org/wiki/Meal,_Ready-to-Eat)

2 - [https://en.wikipedia.org/wiki/Night_vision_device](https://en.wikipedia.org/wiki/Night_vision_device)

3 - [https://www.youtube.com/watch?v=ViL4bAUGuGY](https://www.youtube.com/watch?v=ViL4bAUGuGY)

4 - [http://www.npr.org/sections/alltechconsidered/2013/05/15/184...](http://www.npr.org/sections/alltechconsidered/2013/05/15/184223110/new- rifle-on-sale)

5 - [https://en.wikipedia.org/wiki/11th_Reconnaissance_Squadron](https://en.wikipedia.org/wiki/11th_Reconnaissance_Squadron)

6 - [https://www.youtube.com/watch?v=bQi7iknSKy0](https://www.youtube.com/watch?v=bQi7iknSKy0)

7 - [https://www.youtube.com/watch?v=yC2pnjN4qT8](https://www.youtube.com/watch?v=yC2pnjN4qT8)

8 - [https://en.wikipedia.org/wiki/Nuclear_weapon](https://en.wikipedia.org/wiki/Nuclear_weapon)

9 - [https://en.wikipedia.org/wiki/Unmanned_aerial_vehicle](https://en.wikipedia.org/wiki/Unmanned_aerial_vehicle)

10 - [https://en.wikipedia.org/wiki/Reconnaissance_satellite](https://en.wikipedia.org/wiki/Reconnaissance_satellite)

11 - [https://en.wikipedia.org/wiki/ECHELON](https://en.wikipedia.org/wiki/ECHELON)

12 - [https://en.wikipedia.org/wiki/Nuclear_submarine](https://en.wikipedia.org/wiki/Nuclear_submarine)

13 - [https://en.wikipedia.org/wiki/Unmanned_combat_aerial_vehicle](https://en.wikipedia.org/wiki/Unmanned_combat_aerial_vehicle)

14 - [https://en.wikipedia.org/wiki/M1_Abrams](https://en.wikipedia.org/wiki/M1_Abrams)

15 - [https://en.wikipedia.org/wiki/Directed- energy_weapon](https://en.wikipedia.org/wiki/Directed-energy_weapon)

16 - [https://www.youtube.com/watch?v=o4ZqfEJTGzw](https://www.youtube.com/watch?v=o4ZqfEJTGzw)

<comment><USER13> As a USMC OIF combat vet, it's interesting to see the scientific benefits holistically, but then to realize that unless your enemy wears a uniform and ammasses against you, you are bound to be able to use almost none of these technologies, which is why me and my fellow Marines ended up doing the dirty old style grunt work which was actually closer to policing than it was to warfighting (most of the time).

The point is, generals tend to; A) fight the last war, and B) over-value scientifice/technology solutions.

That's not to negate their importance even for knuckle-draggers, for example, the ability to call in a helo for supporting fire has saved more infantrymen on the ground than you could imagine. I just think it's important to keep technological advances in perspective, (especially in an age where overdependence could create a massive shift in a battlespace if say large radius EMP's were deployed).

<comment><USER14> OEF here. We used our advanced scientific resources to create mine rollers that cost incredible amounts of money. They were defeated by 30 cent worth of wire that allowed the pressure plates to moved 12 feet in front of the explosives.

</comment></comment></comment><comment><USER10> If you want something more like what you thought DARPA should be, check out DIUx: [https://www.diux.mil/workwithus/](https://www.diux.mil/workwithus/)

<comment><USER9> And there is also IARPA and HSARPA:

[https://en.wikipedia.org/wiki/Intelligence_Advanced_Research...](https://en.wikipedia.org/wiki/Intelligence_Advanced_Research_Projects_Activity)

[https://en.wikipedia.org/wiki/HSARPA](https://en.wikipedia.org/wiki/HSARPA)</comment></comment>


Nintendo Switch Presentation 2017 - <AUTHOR> https://www.youtube.com/watch?v=uuC4YLLkqME <comment><USER2> The nerd in me is curious about the USB-C charger. Presumably this isn't USB-C Power Delivery? Assuming 5V, how many MAh do I need in my external battery to run for an hour? How much power does this thing need?

Also, do the JoyCon run out of batteries at a much slower rate like a regular console controller? Presumably they charge when connected to the screen?

<comment><USER3> The USB 3.1 spec isn't restricted to 5V. The charger can deliver up to 100W and the voltage can be negotiated between the charger and device.

<comment><USER2> Right, that's the USB Power Delivery (PD) spec and to get more than 5V, both sides (charger & device) need to support it. I'm guessing (no real idea) that the switch is vanilla 5V like most phones and tablets. Wouldn't mind being wrong.

</comment></comment></comment><comment><USER4> For people who like me, can't concentrate on one language when someone in one language they understand speaks on top of someone else in another language they understand, here is the same video without the voice-over (so, in japanese): [https://www.youtube.com/watch?v=1ti9rFafwTw](https://www.youtube.com/watch?v=1ti9rFafwTw)

</comment><comment><USER5> US Release date: March 3rd. Price: $299. Region free!

<comment><USER6> And Nintendo Switch online services will be offered at a monthly fee, which they didn't present.

<comment><USER7> They did present this, and they also mentioned that the online services will be free at launch and turn into a paid service later.

<comment><USER6> I mean they didn't mention what the fee would be. Or did I miss something?

</comment></comment></comment></comment><comment><AUTHOR> I'm definitely intrigued by the simple kinect-like sensor and HD rumble in the joy-cons. I just hope game developers leverage these unique controls.

</comment><comment><USER2> Showing a demo of a fighting game where a male character repeatedly punches and ultimately knocks out a female character just felt like a missed opportunity to me. How hard would it be to flip that for the demo?

(Already regretting posting this comment)

Edit: And here come the downvotes. You can always count on HN.

<comment><USER8> I mean, it's a fighting game? Generally it involves people/monsters/robots punching other people/monsters/robots.

<comment><USER2> I get it. Most of the people who watch the presentation won't care. It just would have been such an easy change that wouldn't have made the presentation any worse for anyone, and it would have made it a bit better for some. It's not like Nintendo threw this show together in a few hours; they've considered a lot of details.

And note this was specifically human avatars in 3d with clear genders. Non- gendered monsters or robots wouldn't have the same issue. It wasn't a montage either; it was a single match demo.

<comment><USER3> > Non-gendered monsters or robots wouldn't have the same issue

What issue? Please come out and explicitly state what the issue here is.

<comment><USER9> The issue is that he wants Nintendo to engage in pointless SJWish virtue- signaling, and is disappointed they didn't take the opportunity to do so.

The fact that they _didn 't_ do this makes me much more inclined to buy a Nintendo Switch!

<comment><USER3> I get the SJW overtones of his comments, I'm just trying to wrap my head around the logic behind them.

He'd prefer girls beating up guys, or robots beating up robots. Basically, _every combination_ of beating up is okay, except male on female? What?

<comment><USER2> That about sums it up. If you're going to pick _exactly one_ combination, why pick the one that's loaded for so many people? But honestly I wouldn't have even noticed if it hadn't been so unbalanced. Here's the actual video:

[https://www.youtube.com/watch?v=nabG4yPZqFM](https://www.youtube.com/watch?v=nabG4yPZqFM)

She doesn't even land a punch. If it were a back and forth with the dude eventually winning, it wouldn't have stood out to me at all and I wouldn't have commented.

If they had shown several fights and this was one of them, it also wouldn't have stood out.</comment></comment></comment></comment></comment></comment></comment>


Joke of the Week: Microsoft Plans To Charge For Its Mobile Operating System - <AUTHOR> http://gizmodo.com/5473855/joke-of-the-week-microsoft-plans-to-charge-for-its-mobile-operating-system <comment><USER2> I think it's perfectly reasonable to sell a cell phone OS _to the carriers_. If consumers like it, they'll buy it, and the carriers will absorb the cost. Sure, that cost will be passed on the the consumers somehow, but not necessarily in a "windows phones cost more than android phones" way.

All it needs to do to compete successfully with Android is to be more polished, responsive & bug-free (don't get me wrong, I like Android, but those are it's shortfalls.)

Plus, it's still going to be much more open/cheaper than the iPhone OS, which is it's more important competitor (from a market share perspective).

</comment><comment><USER3> The comments on the Gizmodo site provide plenty of reasons to discount this suggestion.</comment>


Exceptions in C with longjmp and setjmp - <AUTHOR> http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html <comment><USER2> Unlike with real C++ exceptions, the "finally" block is not entered if a "return" is used inside the "catch" block. And, of course, in this system, exceptions can be caught only in the function from which they are thrown, unlike real C++ exceptions, which can be caught anywhere in the call stack. But the solution provided here is good, and is probably the best possible one for C.

</comment><comment><USER3> If you ever want to have some "fun" try testing an implementation of this. Like the authors and many others, I've also gone down this road of implementing exceptions using longjmp/setjmp. Writing the code was not nearly as hard as writing tests for every permutation of ignoring, catching, rethrowing, finally'ing, and so on through multiple levels. Then the _really_ good part: seeing how your implementation interacts with ucontext-based lightweight threads. I'll leave that one as an exercise for the reader, because I'm evil.</comment>