phpunit-snapshot-assertions – is an interesting addition to the PHPUnit assertions which allows testing against previously created snapshots. This is particularly useful for testing the outputs of API end-points, format conversion functions, and the like. Instead of testing the actual functionality, these assertions allow to compare the output of the current test run with the known good output of a previously created snapshot.
This works well for generic text, but even better for widely used formats like JSON and XML, where, in case of a failed assertion, a meaningful difference can be provided.
Here is a blog post providing some more details on philosophy and methodology.
Oh. My. God. The future is here. Hellenic Bank is (finally!) introducing an API. Not sure yet what exactly one would be able to do with it, but even if it’s just to check an account balance, it’s progress already.
I vaguely remember being part of the effort to convince Hellenic Bank (or any Cyprus bank for that matter) to provide an API to my then employer … erm … about 10 years ago. The effort was beyond describable at the time. But I knew the day would come, and it’s finally here.
These are probably the biggest technology news since the time PrimeTel became an ISP with its own submarine cables.
GitHub to MySQL is a handy little app in PHP that pulls labels, milestones and issues from GitHub into your local MySQL database. This is useful for analysis and backup purposes.
There are a few example queries provided that show issues vs. pull requests, average number of days to merge a pull request over the past weeks, average number of pull requests open every day, and total number of issues.
I think this tool can be easily extended to pull other information from GitHub, such as release notes, projects, web hooks. Also, if you are using multiple version control services, such as BitBucket and GitLab, extending this tool can help with merging data from multiple sources and cross-referencing it with the company internal tools (bug trackers, support ticketing systems, CRM, etc).
This is not something I’ll be doing now, but I’m sure the future is not too far away.
wuzz – interactive cli tool for HTTP inspection.
Suhas Chatekar explains how they use API maps to visualizing complex APIs, resources those API expose and how those resources relate to each other.
If only there was a tool that would help with this …
Wait, what? That’s exactly what I said when I read this blog post. I am still making my way through the JSON API specification. And now it seems I might be wasting my time, as I should be learning HAL.
Whereas JSON API is almost like an “ORM over HTTP”, HAL does a lot less for you though, so it’s not really an apples-to-apples type of comparison.
HAL really is just a document format for a hypermedia API, like HTML is for hypertext. It doesn’t tell you how to express your domain model, and doesn’t really tell you how to use HAL to submit changes.
Sometime I think that I should just stop learning. What’s the point? By the time you learn a thing or two, it’s already obsolete and somebody somewhere has created something better, or wiser, or cheaper.
OpenAPI Specification v2.0 – formerly known as Swagger RESTful API Documentation Specification.
Swagger™ is a project used to describe and document RESTful APIs.
The Swagger specification defines a set of files required to describe such an API. These files can then be used by the Swagger-UI project to display the API and Swagger-Codegen to generate clients in various languages. Additional utilities can also take advantage of the resulting files, such as testing tools.
Slashdot is running the story about the Google vs. Oracle court case. I thought this bit was rather brilliant:
Schwartz’s second attempt at the breakfast menu analogy went much better, as he explained that although two different restaurants could have hamburgers on the menu, the actual hamburgers themselves were different — the terms on the menu were an API, and the hamburgers were implementations.”
An API is a user interface for developers. Put the effort in to ensure it’s not just functional but pleasant to use.
Vinay Sahni has a rather lengthy, detailed, and well-rounded post on how to design a good RESTful API. It covers pretty much everything from URL structures and parameters, request methods, to error handling, documentation, and coding style.
FOASS gotta be one of the funniest things I’ve seen recently. All we need now are some comments on the API design from all those noisy “this is how you do REST” people. Who, by the way, can f*ck off. :)