Lukas Rosenstock's Blog

I’ve observed that sometimes people use the words “API” and “microservice” and mean the same thing, or they use the terms in other confusing ways. As the famous adage goes, “there’s only two hard problems in computer science, cache invalidation and naming things”, and it seems to be correct when it comes to terminology in the API ecosystem.

I’m exploring these terms, along with containers, in an article APIs and Microservices that now got the more click-baity editorial headline “Stop Calling your APIs Microservices” and has been published in the Stoplight API Corner on Medium. Go and check it out!

Disclosure: This work was paid for by Stoplight.

Thank you for your interest in my talk Specification-driven API with OpenAPI! I have now uploaded the slides to SlideShare.

Tonight I will be at the bits, bytes & bier #3 meetup in the FinTecSystems office in Linden near Gießen and give a talk called Specification-driven API Design with OpenAPI. It will be similar to last week’s talk, but since it’s a meetup targeted at developer, there will be an emphasis on the OpenAPI specification and less about documentation and the role of technical writers.

Thanks to everyone who was at my talk Specification-driven API vs. Technical Writers. If you want to refresh your memory or if you haven’t been at the talk but still interested in the topic you can now get my deck on SlideShare.

I’m at this year’s tekom conference and fair, also known as tcworld18, and I’m about to give a talk titled Specification-driven API vs. Technical Writers. If you found my website because of it, welcome! The slides will be published by tekom after the conference but I will also share them on this site soon.

I’m on a train right now on my way to London. I’ll be attending the API the Docs London 2018 conference and the first DevPortal Awards Gala, where I have the honor to announce the jury winner for the best overall developer portal on behalf of the jury members. This is also a memorable trip because it’s my first time going to London by Eurostar and also probably the last time that this journey doesn’t involve crossing the borders of the EU.

The tech industry has a massive impact on the world and our societies, both positive and negative. Social networks have brought people together but have also been detrimental to privacy. Their broad reach and algorithms have helped with the Arab Spring but also with Donald Trump and Brexit. Smartphones require materials that are often mined by child labor. Data centers draw vast amounts of energy.

A few weeks ago I listed to an episode from The New Stack podcast with Anne Curie of the cloud consulting company Container Solutions. Together with London-based diversity-focussed programming meetup Coed:Code, she organized a conference called Coed:Ethics to talk about the impact of the technology industry and what we as professionals should do.

As she told in the podcast, they wanted to produce some tangible results from the conference, and for that, the UN development goals were an inspiration because they offer a low common denominator that is entirely noncontroversial so that everybody can agree on them.

The result is a whitepaper about the state of data center energy usage in 2018, which is at roughly 2% of the entire global energy usage, and a petition to hosters and cloud providers with a simple goal: run all servers with 100% renewable energy in 2024!

I like this goal, and I’ve already signed the petition, and I recommend you do the same. There’s less than 1000 signatures so far - I think we can do much better! Also, I believe the ecological footprint is an excellent way to start a discussion about the ethics of the tech industry before we move to more controversial topics such as privacy.

A month ago I had written about Manna, the cryptocurrency that is issued as a Universal Basic Income (UBI). It was an article in the Union Square Ventures (USV) blog that caused me to sign up for their service. The list that USV compiled contained a few more intriguing projects but, to get started, I wanted to experiment with only one. A few days ago I came across another interesting article about the intersection of cryptocurrencies and UBI, which listed only two examples, Manna and Swift (which was also in the USV list). So I decided to sign up for Swift as well.

The difference between Manna and Swift is that Manna already uses the blockchain while Swift is a centralized digital currency whose blockchain is under development. As far as its website goes, Swift looks a bit more advanced at the moment, for example, it has a complete shop and an API to build transactions around the system. Another critical difference is that Manna will automatically come to your account once a week whereas Swift comes daily but you need to claim it actively and, if unclaimed, new income payments expire after seven days. That means, if you want to use and collect Swift, you should sign in to their website at least once a week. It could be a crucial feature, though, to drive actual adoption and keep the currency valuable instead of having a large number of non-active accounts (“Karteileichen”) holding the coin.

There’s also a referral program, so if you want to try it, please sign up with my link. I’m curious how this space will develop. If I find the time I will play around with the API and offer some services in their shop.

For APIs to be successful, it’s important that they are functionally correct and that they perform well. Testing is a wide field with a lot of different approaches and terminology surrounding them, and it’s also connected to other aspects of the API lifecycle such as monitoring. I have researched and explained some of the major aspects of API testing and I wrote an article about this. You can read it on the BlazeMeter blog or the syndicated copy on DZone.

Disclosure: This work was paid for by BlazeMeter.

Security is an often overlooked aspect of API design. In another guest post for my client Stoplight I have written about the different elements of API security and how the OpenAPI specification allows you to define authentication and authorization for your API explicitly, but also how a specification-driven workflow helps with security in general.

You can read my API security in OpenAPI article in the Stoplight API Corner on Medium.

Disclosure: This work was paid for by Stoplight.

This is a test post created with the Wrimini app for Android (alpha version).

As you may be aware, I’m interested in Universal Basic Income (UBI). I believe that it is a useful policy for developed countries to counteract the adverse effects of increased automation and flexibility that leads to less job security. At the same time, I also believe that cash transfers, especially if issued as basic income (what GiveDirectly does), are an effective mechanism for foreign aid.

A while ago, I came across an exciting project called MannaBase. Founded initially as GrantCoin, MannaBase marries the basic income idea with a cryptocurrency. Their concept is that everyone can sign up and receive an equal share of the currency. As it’s a cryptocurrency, people can trade Manna at online exchanges, and that’s how the new money gains value.

What I also like a lot about them is that the People’s Currency foundation that issues Manna has plans to build direct giving instruments directly into the platform so that income recipients can redirect parts of their share to people in need based on demographics.

The only downside to Manna that I see is that it’s a proof-of-work cryptocurrency, which are known to be inefficient. That is something that they, just like everyone else in the cryptocurrency space, has to solve if they want to reach mainstream adoption, but the first steps (such as proof-of-stake or lightning networks) have already been made.

As of now, the weekly distribution has a value of around a single cent, but a project like this is a long shot aimed at the future. Also, to grow the community, MannaBase has a referral program!

So, if you also find this is an inspiring idea, why not sign up for MannaBase with my referral link and collect 50% more Manna for a year?! I’d appreciate that :)

You have never created a machine-readable API specification with OpenAPI because you didn’t know how to start?! Lucky for you, I’ve written a practical tutorial that does a little hand-holding and takes you step-by-step through your first OpenAPI file. It uses Stoplight’s visual editor, so you don’t have to code it in YAML or JSON manually, but I also show you how it looks like under the hood, so you better understand how OpenAPI works.

You can find my tutorial in the Stoplight API Corner on Medium.

Disclosure: This work was paid for by Stoplight.

Facebook, Google, Microsoft and Twitter recently announced the Data Transfer Project (DTP) as a way to improve data portability between different services. Naturally, I was intrigued to understand what precisely the DTP is. So I spend a recent ride on the train riding the whitepaper and will give you a little summary here:

DTP provides a Java-based, Docker-deployable open source application that executes bulk tasks with the following workflow: * Authenticate with providers via OAuth. * Export data from one provider through their API and, if necessary, convert it to a standard data model via adapters. Providers can write their own adapters, or third parties can contribute and share them as part of the open source project. * Temporarily store data in encrypted form. * Import data into another provider using their API after, if necessary, converting the standard data model back into the provider-specific format.

A running instance of DTP is called a host. There are different possible models for hosts. One option (distributed) is that a provider itself runs a DTP that allows import from and export to a list of other providers of their choosing. The second option (centralized) is a third party that hosts the infrastructure to exchange data between different providers. The DTP whitepaper suggests that Data Portability NGOs could run such an instance. Finally, the third option (self-managed) means end users are running their own DTP instance.

The DTP only provides software and doesn’t specify any requirements for providers as to with who they have to interact. Every host decides which adapters it makes available and needs to apply for API access with each provider. Also, the whole design of the DTP is for one-time data transfer and does not support continuous synchronization.

My opinion: The DTP is convincing and can certainly help with data portability. Of course, it depends on providers opening up their APIs, although consumer demand and data portability requirements (as in the GDPR) could drive them. Its scope is limited, but I think its data models could be applied even outside this scope for federation and interoperability (or they could become “just another standard …”).

I came across the Kickstarter crowdfunding campaign for Openbook. They call themselves “The honest, open-source & awesome social network”, and their plan is to build a “Facebook competitor” that is open sourced, free of advertisements, and wants to donate a portion of their revenue to charity - but apparently is not decentralized or federated.

I’m not sure what to think about it. On the one hand, I believe we need more alternatives to Facebook, except then I remember that the problem is not that other options don’t exist, but that network effects work against them. It’s already difficult for social media to grow through some hype, venture capital, and unique features. Being “Facebook, but open” is a tough value proposition to sell. I still wish them luck. Their design mocks look fine, and the team also seems solid; they have a founder of PGP on board as well as some non-technical people that could help make Openbook something that doesn’t just cater to computer geeks.

Machine-readable API specification formats like OpenAPI are not just for creating documentation but can be a driver for the whole API lifecycle. If you generate them from code you’re leaving half of what OpenAPI can do on the table, so it’s better to develop a specification-first API workflow.

I wrote about this topic as a guest post for Stoplight who offer cloud-based tools around OpenAPI and API design. You can read it in the Stoplight API Corner on Medium.

Disclosure: This work was paid for by Stoplight.

I’m back home in Germany after my two-week workation in Gran Canaria. These two weeks were a great experience but also way too short; as I had a lot of work to do I couldn’t explore as much of the city or the island as I wanted to. So, sooner or later, I have to go there again!

I saw the documentary Banking on Bitcoin last night. The main reason I watched it was that they hosted a screening at this very nice co-working/co-living place called The Roof here in Las Palmas. Regarding the movie itself, it’s obviously outdated since it’s from 2016 and a lot has happened in the cryptocurrency space since then.

What I liked about it: it does a good job demonstrating the beginnings of Bitcoin from the cypherpunk movement, the first startups in the space and their regulation issues as well as the search for the identity of Satoshi Nakamoto. From that perspective, I can highly recommend it.

What I didn’t like about it: the movie contains practically no criticism. Issues like scalability are glossed over, and others like the inefficient use of energy are not mentioned at all. You end up thinking that Bitcoin is without a doubt this great technology that just has to go through growing pains.

I arrived in Las Palmas de Gran Canaria today! For the next two weeks I will be working from the lovely ReStation co-working space and enjoy my free time exploring the city and the beach.

I’ve written and published an article, in which I describe how to create API test cases in Postman and then run them both within Postman as well as its command line companion Newman and finally export the collection from Postman and import it to BlazeMeter for cloud-based functional API testing.

If you’re curious you can read the article on the BlazeMeter blog or the syndicated copy on DZone.

Disclosure: This work was paid for by BlazeMeter.

As promised, I wrote an article about my experience at API the Docs Paris 2018. It’s published on the CloudObjects blog. Looking forward to your feedback!

I’m on a train on my way back home from Paris, where I had three great days! I arrived on Monday and spent the afternoon exploring the city a bit, then met some of the conference attendees for dinner. On Tuesday there was the actual API the Docs conference day at the beautiful Mozilla office. There were interesting speakers and more nice and interesting people to talk to. I’ve started writing a blog post about the event and the talks which I’ll publish on the CloudObjects Blog soon. This morning before leaving I went to see STATION F, the world’s largest startup campus, located in Paris.

I’m happy to announce that not only will I be attending API the Docs in Paris on April 24th, but my talk proposal “To SDK or not to SDK?” has been accepted by the conference committee. Currently I’m working on the talk and look very much forward to giving it in Paris soon.

After long consideration, I decided to create a hosted Microblog on Now I need to set this thing up.