Milagre

So all the attack vectors the NSA has used to date are based upon backdoors (voluntary or otherwise) to existing vendors?

Something I've been confused and/or mislead about is that if root/CA ssl certificates are compromised, then all derivative ssl certificates are also compromised. Is this true? Are these some of the companies the NSA has 'backdoors' with?

Sorry, I'm not even sure about the terminology here -.-

> When you start with the point of view that we are all reasonable, and well intentioned.. the problem then becomes about process and culture, and you can actually start making progress.

In my studies of nonviolent resistance, this was the core message: People act on what they feel is the right thing to do at the time. If the world deems that wrong, that's a different discussion, and a learning experience for both the world and the actor.

In order to make progress, you must empathize with that person, communicate with them on their terms, and open a discussion on both of your beliefs without judgement.

+1 jonmc12 for your point of view.

> Hypermedia APIs expose a workflow, not a data model.

I would say this is true of REST APIs. Not necessarily hypermedia APIs. An API that directly exposed a graph database as an HTTP-based API using hypertext/links within resources would still need to be classified as a hypermedia API, but would fail to adhere to the HATEOAS principle.

Edit: More specifically - a graph database that exposed itself with links for every edge and a resource for every node.

> Sure css, js etc are fetched, but this is hard-coded behaviour, there is nothing dynamic or discovered about it. Or I fail to understand it.

It grabs the links from the content of the document it retrieved, using the rules of HTMLs structure to find them. That's both dynamic and discovered.

This is a fair point!

Mostly, I think that would produce an ugly API.

The reason I've been leaning towards that solution is that it assigns the responsibility of locating any other resource, in one request, with full backwards compatibility, to exactly one location, freeing other locations to change in a more fluid and graceful way without the cruft.

Edit: Oh and because other URLs can have the context of their parent paths deliver some value or information. But then again URLs should be opaque =). Definitely worth thinking more about!

> This kind of thing sounds great for exploratory development, but undesirable (for the reasons I outlined previously) for an actual production app.

We actually do this in our production app. The only URL we actually hardcode in the app is the root URL for the account currently logged into. (And a few other urls unrelated to the account, but that's honestly just pure laziness).

User logs in - we get the account (root resource)

Bootstrap the JS - we get a subresource of the account and request it, populating the initial UI

User interacts with UI - generates a GET to a URL we got from another resource, repopulates the UI with relevant data from that resource. Rince, repeat.

Doing this has made changing our API structure over the course of development a lot easier.

> I hope you're used to waiting :).

I am :). But I look at how much faster html5 went from concept to production because it was pushed by the browsers, and I experience an $optimism++. Things are moving in the right direction, IMO.

> Apart from parsing, I am the API client in this instance. I'm the one making decisions from understanding what services are about.

Your browser parses, yes, but then it goes and fetches images, css, javascript, iframes, etc. Following the analogy, these are 'api calls'. It knows to make these calls because the HTML defined the links, and for the HTML to be rendered the contents of the links are required.

I maintain the browser is the client - it responds to your actions, but it does so with a lot more activity than just parsing.

>What makes hypermedia interesting IMHO is (minor point) easier intra-linking within a webservice, and (major point) the ability within a service to point to resources from another one. > >This will enable the distributed web we are all waiting for.

Couldn't agree more. But without some standards, those links to other services may not be as useful as they could be.

OP here.

I'm not strictly advocating HATEOS. Hypermedia and HATEOS are related but not the same concept. I am very strongly advocating hypermedia, as I believe it it greatly reduces the complexity of interacting with an API.

Never having to build a URL by hand is great! Being able to just grab a field from a resource, and go do a GET on its value is very easy to code, even if that process involves finding a link with a certain relation. You speak of complexity, and I'm speaking of convenience.

With that convenience also comes the ability to automatically crawl the data with good solid knowledge of how each resource relates to others, enabling the ability to create massive graphs of information. Like wikipedia has for humans to read, but structured and standard for computers to parse.

> His theoretical (well, implementations certainly exist) universal REST client only works when every API you want to consume standardizes to presenting the information in the same format.

That sounds like a great day to me.

You'd be smart to ask "Which ones?" before you dismiss all dev blogs as 'horse shit'.

Blogs like Coding Horror and Object Mentor should gain your respect, not your disdain.