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.Read on →
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.Read on →
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.Read on →
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.Read on →
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
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.