There are many MVC frameworks out there and all of them share a common feature - routing. Most libraries use a form of URI patterns to match incoming requests. On top of powerful features like limiting allowed values to certain types or by using regular expressions, they all share a common flaw - great simplification of the URI.

There is however a similar proposed standard described by RFC 6570 and appropriately called URI Template As the name implies, it defines URI patterns which can be then expanded to actual URIs by substituting variables and work the opposite way by extracting variables from a given URI. This makes it a viable option for matching request URIs on the server to determine what code to execute, if any.

There are a number of guidelines for returning errors from a REST API in a consistent way. Of course, API authors should use status codes correctly to signify the result of an action. It is also a good idea to return some error details in resource representation. Some API vendors, like Facebook or Twitter have come up with their own solutions.

However, there is a Internet Engineering Task Force (IETF) proposed standard called Problem Details for HTTP APIs. It was created be Mark Nottingham and is described in document RFC 7807. Interestingly though there is fairly little support in for .NET Web API libraries and none for Nancy 1.x.

I love consuming custom elements but writing them in Polymer with ES5 is far from ideal. ES6 (or more correctly ES2015) could offer some improvement but it is still not officially supported by the Polymer team and their toolset.

Thankfully, there is PolymerTS which offers a vastly improved Polymer API, mainly thanks to decorators. It also let’s developers take advantage of ES6 modules but there is one problem: how do you publish elements with dependencies both on JSPM packages and other elements from Bower?

Earlier this week I shortly wrote about the first day Research Track at International Conference on Web Engineering which took place between June 6-7. Today it’s time for day 2 (keynote included).

This past week I took part in the International Conference on Web Engineering or ICWE for short. I’d like to round up the lectures I attended, demos I watched and posters I saw. While I still remember, I want to write about my impressions about each individual one, at least at the very shortest. Of course I won’t be able to cover it all, because I wasn’t able to attend every session for obvious reasons and at the same time I didn’t find everything equally interesting. I’ll do my best nonetheless.

I’ve just discovered an interesting JavaScript quirk which I haven’t seen before. It turns out that indexing an object with a single element array has the exact same effect as indexing with that array’s element.

I’ve been going on about hypermedia for a long time now. I’ve touched both client and server side in terms of processing resource representations. There is however a big missing piece in how developers should build user interfaces. Personally I have been hooked on the idea of Web Components and I’ve had some success experimenting with using a declarative way for defining User Interface building blocks.

Most hypermedia media types like HAL or SIREN are some sort of extension of JSON, which is understandable. JSON is a natural choice because it already is the most common data interchange format for APIs. However JSON as syntax is by design simple and it doesn’t support vital part - links. To plug that hole these media types are intrusive in that they impose a very specific structure of documents. Instead of extending the meaning of representations they hijack the syntax and structure.

Personally I’m biased towards Hydra Core Vocabulary because, unlike all other I have come across, it is based on RDF. Why is it important?

Going full-on with hypermedia takes some preparations and to convince the masses will require some tooling and examples. Especially tooling. The ability to produce rich developer experience is the determinant of many successful technologies. Another crucial factor are real-life uses cases solved by the technology in question. I would like to focus on the former.

As much as the industry has bought into lightweight Web APIs, often inappropriately called RESTful, there has been an uphill battle to have real hypermedia gain traction.

In my previous post I presented the first incarnation of Heracles, the Hydra Core client library. While trying to replace my makeshift client I’d implemented for an in-house training project at PGS I quickly decided that I’m going to need a way to compact my resources. It wasn’t that hard but there was one simple hurdle to overcome.