On privacy, data ownership and self sovereign identity and the race to get there first.

People in the business know that companies 2.0 compete for our attention; a fierce competition with smaller and smaller margins (of attention). The end game is clearly advertisement. The pattern, simplistically, is:

1. user uses the service for free (or for very little money), 
2. company stores the data and profiles the user, aggregates profiles, does fancy Machine Learning magic, etc
3. company uses the data and derived information for targeted advertisement or (shock!) sells it to third parties for other lucrative endeavours.

Simple and effective.

Finally, people is getting more and more aware of what's going on (don't you, sometimes weirdly, feel like you're followed or even been scammed?); law makers are catching up to get a fair share of the revenue and economists are adjusting their theories to explain recent blips in their Capitalism models.

A trend is emerging where anonymity and privacy are becoming more and more important for users; and companies do make an effort to protect such users (from themselves?).
To the extent that some of them have announced changes to their business models. Facebook is paving the way.

This is definitely a step in the right direction but it's clearly not enough. Data is still stored in these companies' data stores and, moreover,  still - somewhat - traceable to a person.
Yet, we're seeing more and more efforts to frame the problem of data ownership in a lots of ways, some more creative than others.

Technology is also catching up (one of the many systems trying to tackle the issue is OpenPDS). And in the space of digital identity, self sovereign identity - users owning their digital identity much like they own their passport or identity card - is also being developed as a concept with associated technologies.

The problem, right now, is that companies haven't caught up as they haven't yet figured out how this switch will eventually affect their bottom line (read: make shareholders richer).
Implications, then, are that

• tools and processes for the end users aren't yet developed for mass market adoption: think, for a moment, about how easy(!) is to use a crypto wallet.
• incentives to move to this new model are virtually non existent so we can't really talk just yet of a new 3.0 model... maybe we can settle with a 2.5 though.

But - in a way - it's easy to see how this will eventually work. Companies will compete for that data: as if you were strewed with gold dust they'll knock at your (digital) door to come and swipe some of it. "Please, give us access to your browsing history for last month of May for the opportunity to win a trip to the Maldives!"; or: "Give us your Facebook timeline for last year to get a 10% grocery store discount for a whole month". And - make no mistake - we'll give it away (agent Smith echoes in my mind).

There will also be less mundane opportunities, obviously, which will generate new revenue streams ad new creative opportunities. A simple example comes to mind: "Hello A.C.M.E, here is access to my smart home data, please monitor it for intrusion detection and to activate my irrigation system when needed, whilst I am away. Oh, also please feed the dog, will you?!").

As long as this is done with fair, open and clear rules that guarantee the weakest users (like children and people with mental health issues, or the poorest) it's all welcome. 

In fact, forward looking enterprises should be pivoting right now and contribute to pave this new way in their respective market segment. Clearly, it's challenging: not only they need to embrace the risk of adopting cutting edge technologies, but also create new processes and redefine their identity if necessary. 

But the sooner they start the less the risk is to be caught by surprise. And maybe some of them will hit the jackpot and make it into the list.

   

Get FitNesse with some Rest

UPDATE: code moved here: http://github.com/smartrics/RestFixture

UPDATE II: Thank you to Steven Haines for the clear and concise Howto giude on the RestFixture.

I am currently involved in building a REST API. Our direct customer proxy (the architecture team) needs to "understand" how we implement the agreed acceptance criteria and it has also asked to document the API.
FitNesse is our tool of choice for writing functional Customer Acceptance Tests; we currently use it to implement this type of tests for other parts of the system we're building. So it came natural to start using it for documenting the API.

At first we implemented the tests using essentially ActionFixtures. The approach adopted consisted of "wrapping" the REST API in more descriptive metods that could be pressed, checked and entered.

After the first dozen of tests it was apparent that this approach was not ideal. Tests were not clear enough and maintaining the fixtures was hard and time consuming as the amount of code duplication was high for any standard. New tests required us writing more code and, in fact, we were testing just the behaviour of the backend without giving enough exposure to the API itself - consequently, our tests were not descriptive enough to work as live documentation.

So I decided to write a new "type" of fixture, inspired by the ActionFixture, the RestFixture.

The core principles underpinning the decision to write a new fixture were the following:

• For documenting a REST API you need to show how the API looks like. For REST this means


• show what the resource URI looks like. For example
/resource-a/123/resource-b/234
• show what HTTP operation is being executed on that resource. Specifically which one fo the main HTTP verbs where under test (GET, POST, PUT, DELETE, HEAD, OPTIONS).


• have the ability to set headers and body in the request


• check expectations on the return code of the call in order to document the behaviour of the API


• check expectation on the HTTP headers and body in the response. Again, to document the behaviour


• I didn't want to maintain fixture code. If I could only write the tests...
• I wanted to be able to let the customer proxies to write the tests... And they understand Wiki syntax more than Java.

The RestFixture at a glance

The RestRixture is an ActionFixture, therefore all the ActionFixture goodies are available. On top of that it contains the following 7 methods:

• header: to be able to set the headers for the next request (a CRLF separated list of name:value pairs


• body: to allow request body input, essential for PUT and POST


• let: to allow data from the response headers and body to be extracted and assigned to a label that can then be passed around. For example our API specifies that when you create a resource using POST, the newly created resource URI is in the Location header. This URI is necessary in order to perform further operations on that resource (for example, DELETE it in a teardown).


• GET, POST, PUT, DELETE, to execute requests.
  

Each test is a rown on a RestFixture table and it has the following format:

|VERB|uri|?ret|?headers|?body|

• VERB is one of GET, POST, PUT, DELETE (at the moment we're not supporting HEAD and OPTIONS)


• uri is the resource URI


• ?ret is the expected return code of the request. it can be expressed as a regular expression, that is you can write 2\d\d if you expect any code between 200 and 299.


• ?headers is the expected list of headers. In fact, the expectation is checked by verifying that *all* the headers in here are present in the response. Each header must go in a newline and both name and value can be expressed as regular expressions to match in order to verify inclusion.


• ?body it's the expected body in the response. This is expressed as a list of XPath expressions to allow greater flexibility.

Some examples

The following pictures are snapshots taken from FitNesse with the aim of providing examples of usage of the RestFixture. The notes before each test explain the details of the fixture itself.








It's worth noticing that, generally, expectations are not matched by string comparing the expected value with the actual value. Expectations on headers are verified by checking that the expected set of headers is included in the actual set of headers, similarly with the body where expectations are matched by checking existences of nodes for a given path.

Conclusions

The RestFixture allows to write FitNesse tests without having to write any Java code to back up the fixtures. Tests are clear and easy to read/write and this obviously improves their readability. Therefore it works well for documenting the API and the behaviour of the system under test. Looking it from another angle, the fixture, essentially, implements a REST DSL, that allows customers to write tests on their own.