This will be the last part about REST mistakes and confusion for the time being. In this post I will share my opinions about common approaches to versioning REST APIs. I will also present my view about why and how versioning could be avoided.

In this installment of my REST series I will take on the train wreck, which some people call REST API documentation. Of course some form of documentation is necessary but I am growing more and more disappointed with most current solutions. Tools like Swagger or Apiary can be used to create some sort of documentation, but they sure as hell don’t describe REST APIs.

This part four (0-based) of my series about REST, the mistakes people often make and some ideas of mine. This post on talks about taking advantage of resource representations in a javascript client. This is somewhat related to my other REST post, where I argue that when resources are properly identified and actually linked is should be possible (and beneficial) to ditch client URL routing.

Previously, in my first #dajsiepoznać post, I wrote about how I’ve been trying to create wikibus.org, the public transport encyclopedia. Sadly, Most of that development has been more of blind technology exploration, learning and very little delivery. Now, I’m going forward with renewed strength, and I’d like to share more details about the idea behind the project.

For anyone interested in the Semantic Web, data storage continues to be an issue. Although there is a fair number of triple- and quadstore, your mileage may vary. Some triple stores offer mediocre performance, there are stability issues, missing features or unsupported platforms. There however one simple, but hassle-free alternative in the cloud.

In the fourth part of my REST series I will expand the idea of links. Links are just a stepping stone no matter how important. Simple links aren’t enough for the client to interact with the server. After all how is it going to know when to POST and when to PUT or what are the required parameters and request bodies. This is where affordances come into play. It means that the server should include all information the client needs. Just as defined by the self-descriptive constraint.

I’ve been building my wikibus.org code on AppVeyor, which is quite neat and used it to publish over WebDeploy to my VPS. Having recently watched a convincing presentation about Heroku on Wrocław .NET User Group I decided that maybe it will be an interesting experience.

My colleague Jarek Stadnicki convinced me to join the competition called Daj się poznać (Polish for Let them get to know you). Here are a few words about that and what I will be doing

In the third installment of my REST misconceptions series in which I explore hyperlinks. Links are an essential part of a REST API as has been written down by Richard Fowler in his article about the Richardson Maturity Model. Wonder why links are important? Please, do read on.

Instructions for setting up Babun (zsh) as Webstorm terminal. I’ve recently been shown Babun and having it replace GitHub for Windows shell in Webstorm was the last piece of my happiness. The tricky part was to have it open in the current working copy and not the default home path.