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. :)
OverAPI.com – Collecting All Cheat Sheets
Twilio – APIs for Text Messaging, VoIP & Voice in the Cloud.