Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Register a media-type with IANA #61

Open
gtramontina opened this issue Jul 3, 2017 · 2 comments
Open

Register a media-type with IANA #61

gtramontina opened this issue Jul 3, 2017 · 2 comments

Comments

@gtramontina
Copy link
Contributor

Hey everyone,

Here's something I've been willing to bring up but am just taking the time write now…

It is my understanding that Jasonette understands a very specific json format called Jason, correct?

Assuming the above is true, what do you think about registering a media type with IANA? I'll list down some name options that come to mind as examples of what I mean and then I'll expand of the benefits of having a registered media type.

  • application/vnd.jason+json (this would be my preference given the format name is Jason)
  • application/vnd.jasonette+json (kinda weird as jasonette is the name of the "browser", not the format)

There's a concept called content negotiation, where client and server can exchange information using the Accept and Content-Type headers to communicate, respectively, what the client is able to understand (preferred format) and what the server responded with. This way we can have a single entry point into our systems, for example https://example.com, and serve different representations when possible. A normal web browser would hit the above URL with Accept=text/html and we can simply respond with an HTML representation of requested resource. Jasonette would hit it with Accept=application/vnd.jason+json and we can simply respond with a Jason representation of that same resource.

Using application/json on its own does provide any clues about format semantics. A media type, like application/vnd.jason+json tells clients that they can use a JSON parser (+json) to read the contents and, together with vnd.jason, use the dictionary (meaning) defined by the Jason format. Here's a somewhat recent Hacker News thread on the subject regarding a new json-based format someone created (quite lengthy though).

On the client side, for example, Jasonette could implement (handle) different media types besides Jason, just like regular web browsers do when you follow a image/png resource, or even a video/mp4 resource by understanding the Content-Type and running the appropriate parser/renderer.

Hope we can get a conversation started and move this forward!

@maks
Copy link
Contributor

maks commented Jul 4, 2017

Yes, since it's a specific json schema, makes sense to do this.

@gliechtenstein
Copy link
Contributor

I can understand this is meaningful theoretically, but I am not yet understanding how this can be immediately beneficial to anyone in a practical manner at the moment. Maybe if you could share a specific hypothetical scenario where this makes sense, it would help me better understand.

I am asking specifically in the context of what Jasonette is today. Maybe in the future it will grow into something where having its own content-type will be meaningful but today no Jasonette user has problem with the lack of content-type problem. They simply create a separate JSON endpoint for returning the JASON markup and that's that.

Also regarding your comment on "a JASON representation of the same resource", but I am not sure this is the right way to think about this. For example if we think about a typical web app, it consists of Javascript files, CSS files, and an HTML document. When a website loads it makes several requests each with its own content-type (text/css, text/javascript, text/html).

Coming back to Jasonette, the power of Jasonette is it lets you describe equivalents of all of the above in JSON. We describe action (equivalent to text/javascript) in JSON, We describe styles (equivalent to text/css) in JSON, we also describe the view itself $jason.body (equivalent to text/html) in JSON. And on top of that we have mixins which lets you merge all these different formats together, which blurs the line even further. The whole point of Jasonette is there is a single unified markup type that lets you express every aspect of an app. So a content type like application/vnd.jason+json doesn't really do it justice in my opinion.

Overall, I feel like trying to categorize what Jasonette's markup is at this point will only constrain its potential going forward.

But like I said, maybe I'm not seeing what you're seeing. Please let me know if I'm missing something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants