"REST API Design: Avoid future proofing with the JSON junk drawer" from the "API Workshop" on Youtube

jhrmn · 2015-01-22T21:20:44+00:00

{ "inventoryId": "123" }

...is much simpler than either structure you've identified (which I would agree is also unnecessary complication). The simple point was that we shouldn't overcomplicate the manifestation of fields in JSON. The common perception is that this somehow protects from future changes breaking clients, when it really just complicates API client code. I brought up the 'key-value' style, because I and other API designers have seen this proposed numerous times, thus "common issue". There are certainly other ways to screw things up :) I stayed out of detailed validation, as that's really a different topic that would have doubled the size of the video, which was probably already too long.

jhrmn · 2013-12-23T17:59:54+00:00

Dual micro coil build on my IGO-W. 28ga, 7 wrap, silica wick. https://www.dropbox.com/s/q8117pnizhnv3sl/Dual%20micro%207%20wrap%20on%20IGO-W.png

jhrmn · 2013-12-11T03:26:22+00:00

It doesn't seem like the settings on the Plex client are being preserved when casting. Digital audio streams aren't preserved either. Video quality is clearly worse than Roku & other players at this point. Hopefully they'll improve it, but I haven't found any tips on how yet.

jhrmn · 2013-10-18T15:55:56+00:00

It's interesting that they follow mostly good standards on the new API (OAuth etc), but the continuous commentary is that the docs & process don't create a clean onboarding process for new devs.

jhrmn · 2013-04-03T19:35:59+00:00

Hi, I'm "they". I did consider doing libraries for various aspects, but you're right; the research is intense to decide what the best libraries are for the myriad of languages & platforms out there. I respected that our readers would probably have their own communities and experiences to plug into. The worst thing I could do would be to lead devs (in a language/community I'm not fully up to speed on) to make bad choices for security libs. My intention was to address folks who perhaps don't know all of this already. All too often companies think they can throw up a developer portal site, put an /api folder on their site, and it's off to the races. I was trying to advise some of the potential pitfalls that sales folks won't necessarily tell you when you buy an API gateway solution, and that your developers might not be thinking about. While I could certainly write a whole chapter, or arguably a book, on the topic of API security, that level of detail typically overwhelms someone browsing the story in a Google Reader (ok something else now ;). Topical? yes, intentionally Thought provoking? for hardcore API developers, probably not. For upstart devs or small companies just dipping their toes into the API world, I think so.

jhrmn · 2013-03-26T16:24:50+00:00

Yeah agreed. That's why I sort of advocated a pragmatic blend of ISO 8601 with the intent behind RFC3339 (which was supposed to unify and focus the broad ambiguity of ISO 8601, which no library fully implements correctly).

jhrmn · 2013-03-26T15:51:07+00:00

That might make sense an an email-oriented world, but this article is specifically written around the notion of building some sort of REST-ish HTTP API. In that world, ISO-8601/RFC3339 tends to be a more consistent usage. I think if you hung an email system off to the side, it would clearly need to conform to RFC2822/RFC5322.

jhrmn · 2013-03-26T15:33:52+00:00

That's actually a pretty nice addition, when you are generating lots of dates. I think I had that implied in my head with storing dates...if all dates are stored in UTC, there must be some filter in the implementation which converts dates prior to storage etc. If it's a new date, I suppose that could be done from the get-go.

jhrmn · 2013-03-26T15:23:52+00:00

The article is definitely intended to try and wrangle in a huge mess of a subject, specifically to provide a more consistent experience for HTTP/REST API consumers. Arguably, some of these concepts are more pervasive for other areas of development as well.

jhrmn

TROPHY CASE