Hacker News Reader

Comment by smoyer | Hacker News Reader

Maybe I'm in the minority but I don't want light-weight at the expense of compatible/standard. It's being recognized that validation is more important than we'd expected - the recent ACM guidelines for moderation on Postel's Law really resonated with my experiences with RESTful/JSON micro-services (https://queue.acm.org/detail.cfm?id=1999945). But if we're going to the effort of validating, let's do it in a language/framework agnostic way ... jsonschema.org is mentioned in other comments but I'm a fan of the OpenAPI initiative (https://www.openapis.org/). Then we can all share the validation rules!

View on HN

I understand. In my experience, the usability of those standards is pretty bad. Which in effect leads to projects not using anything at all.

One of the benefit of JSON over XML is that it is concise and fast to work with. The standard should reflect that part as well.

With this lib, as a developer to verify a JSON for a simple REST request is as simple as - `verify(json, "{a,b,c}")`

> leads to projects not using anything at all

We're counting that against products when we're analyzing what services to adopt/purchase. You doing nothing at all ... or something non-standard results in everyone else having to attempt to do it for you with the resulting inconsistencies. I'm not sure why you think OpenAPI is tailored for XML ... Here's the specification for the sample application (petstore) with service and model definitions in YAML - https://github.com/OAI/OpenAPI-Specification/blob/master/exa....

I think we are talking about different things here. I love OpenAPI and wouldn't do a project without it. verify-json is a lightweight way to validate JSON schema and does not intend to change/improve anything about OpenAPI.

This is more for client-server JSON schema validations, comes handy when different teams are writing client and server side code. Especially in startups where iterations are rapid.

A long time ago in a galaxy far, far away, Corba implemented ICDs as "contracts" between parties. It seems like a client and server developed by different teams is still a good use-case for "something" that specifies the contract. In the 2000's, we wrote mil-spec style ICD documents that we attempted to enforce when writing code that had to interact (via a message bus). The benefit of a language/framework agnostic way of performing with something executed in code is a great step forward from just having an ICD document. Note that early Corba, XML-RPC and SOAP/XML could perform this function but people did horrible things to the data (using an indexed array of strings as parameters) that broke both typing and the ability to do type-specific validation.

From the way you've phrased your comment, I'm going to assume that the different teams are within the same start-up ... having a versioned, executable is even better when iterations are rapid if there are breaking changes. I've been in enough start-ups to know that things are skipped over to get a product out the door. I also know that the marketing and sales guys will say "we're already using a RESTful/JSON API for our back-end, let's open our API to third-parties to accelerate adoption of our SaaS". Ouch! (but I've been there)

I will admit that "back-filling" an OpenAPI specification for an existing service can be pretty daunting ... it's quite a bit easier if you start with the first MVP and iterate the ICD with each iteration of the client and server. Admittedly, we (software developers) still have issues versioning services. It's not so bad for incremental changes but breaking changes to a service where you have to support both older and newer clients is painful.

Reply on news.ycombinator.com