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 →

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.

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 →

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.

Read on →