Do I need a JSON replacement? In the wake of an article about KTV
In general, I planned to publish about KTV for links from other articles, so that when I publish them (for example, this one, about S2 ), it would be possible to refer and there would be no questions about what KTV is and where it came from. But the topic was sick. Therefore, I decided that it was necessary to tell a little more about where the idea came from, such a strange at first glance.
Attached to the article polls. Help me, please, understand the situation. :-)
When I did Ă…SS , I needed a data format for writing styles. I chose JSON. For many reasons, the main of which is obvious. The format is good and fast (I compared) parsing, plus it is extremely simple. This means that I can in those very lines (I have two on them, the name and the value) - stuff everything and then interpret it as you like. On the one hand, this is convenient, on the other - the fragility of this system is completely inadequate. Especially when we work with a strictly typed language like Swift.
I also wanted to be still perperit, and not just strings (arrays, associative arrays), that is, that their names were identifiers, and not something strange-with-spaces. This will allow in the near future, for example, to write a plugin for AppCode or for Sublime, which will check the correctness of their writing and highlight if something is wrong. It may be autocompletion for @ -links, and so on.
')
I also lacked several types. The color is the easiest and most necessary for the styler, so I started with it in KTV for S2. But in KTV there will be other "native" types.
Working in outsourcing, you have to constantly implement various APIs in a mobile application. The degree of “ingenuity” of the people who write it sometimes cannot be assessed, this is a fantastically strange construction. And the main reason for such constructions is JSON. It allows you to do anything, whatever. Clever people try to limit this flight of thought, excellent projects like http://jsonapi.org are obtained, but it seems to me that as long as JSON remains in the format, nothing will move. It’s not for nothing that Kotlin , Swift appeared , where even null / nil isn’t just appropriated, a special type is needed for this.
Take, for example, getting a feed post, say, a blog about cars. There is a list of posts with likes, from where there are links to users, their cars. One user can have 10 posts and 20 likes. Is it worth duplicating a user in a post / like every time (and not only in a post, there are, after all, users who have posted posts or commented on them)? No, definitely not worth it. We solved this with the help of ID and flat lists of objects that are inserted when parsing where necessary. But, as it seems to me, it is more convenient to add this functionality to the format. Then you do not have to reinvent the wheel every time, there will be an obvious way to realize this opportunity.
The article showed that, of course, you need a solution to all these problems. The polarization of opinions, the lack of a single direction in solving this common problem, “and I feel good,” reminds me of XML vs JSON disputes. In no case do I want to say that KTV is a thing that will become “the next JSON,” but something needs to be done about this so that each server and each client developer (I’ll point out that clients are not only the web, but also mobile apps and other servers) stopped inventing something of their own. Too much effort is spent on interaction and on invention.
At the same time, I think the path chosen by the guys on http://jsonapi.org is wrong in the long run. By itself, it is excellent. I just do not believe that the whole community can be made to follow these recommendations. We have already passed this, this is XML-RPC, this is SOAP. All this is an attempt to clamp the free format within the framework of agreements. As experience has shown, it is not clamped (more precisely it is clamped, but only within the scope of the enterprise). Only a new, rigid format that is used everywhere will be able to force developers to synchronize and form APIs in the same way. At least simple.
Will KTV help in this direction? I don’t know. He is a couple of months old, still a little stupid. It can grow into a full format, it will be great. No, it is also excellent, I hope, another, more qualitative challenger will appear on his wreckage.
Attached to the article polls. Help me, please, understand the situation. :-)
The first reason is Ångström Style System
When I did Ă…SS , I needed a data format for writing styles. I chose JSON. For many reasons, the main of which is obvious. The format is good and fast (I compared) parsing, plus it is extremely simple. This means that I can in those very lines (I have two on them, the name and the value) - stuff everything and then interpret it as you like. On the one hand, this is convenient, on the other - the fragility of this system is completely inadequate. Especially when we work with a strictly typed language like Swift.
I also wanted to be still perperit, and not just strings (arrays, associative arrays), that is, that their names were identifiers, and not something strange-with-spaces. This will allow in the near future, for example, to write a plugin for AppCode or for Sublime, which will check the correctness of their writing and highlight if something is wrong. It may be autocompletion for @ -links, and so on.
')
I also lacked several types. The color is the easiest and most necessary for the styler, so I started with it in KTV for S2. But in KTV there will be other "native" types.
The second reason is the API
Working in outsourcing, you have to constantly implement various APIs in a mobile application. The degree of “ingenuity” of the people who write it sometimes cannot be assessed, this is a fantastically strange construction. And the main reason for such constructions is JSON. It allows you to do anything, whatever. Clever people try to limit this flight of thought, excellent projects like http://jsonapi.org are obtained, but it seems to me that as long as JSON remains in the format, nothing will move. It’s not for nothing that Kotlin , Swift appeared , where even null / nil isn’t just appropriated, a special type is needed for this.
Take, for example, getting a feed post, say, a blog about cars. There is a list of posts with likes, from where there are links to users, their cars. One user can have 10 posts and 20 likes. Is it worth duplicating a user in a post / like every time (and not only in a post, there are, after all, users who have posted posts or commented on them)? No, definitely not worth it. We solved this with the help of ID and flat lists of objects that are inserted when parsing where necessary. But, as it seems to me, it is more convenient to add this functionality to the format. Then you do not have to reinvent the wheel every time, there will be an obvious way to realize this opportunity.
Do we need a new format at all?
The article showed that, of course, you need a solution to all these problems. The polarization of opinions, the lack of a single direction in solving this common problem, “and I feel good,” reminds me of XML vs JSON disputes. In no case do I want to say that KTV is a thing that will become “the next JSON,” but something needs to be done about this so that each server and each client developer (I’ll point out that clients are not only the web, but also mobile apps and other servers) stopped inventing something of their own. Too much effort is spent on interaction and on invention.
At the same time, I think the path chosen by the guys on http://jsonapi.org is wrong in the long run. By itself, it is excellent. I just do not believe that the whole community can be made to follow these recommendations. We have already passed this, this is XML-RPC, this is SOAP. All this is an attempt to clamp the free format within the framework of agreements. As experience has shown, it is not clamped (more precisely it is clamped, but only within the scope of the enterprise). Only a new, rigid format that is used everywhere will be able to force developers to synchronize and form APIs in the same way. At least simple.
Will KTV help in this direction? I don’t know. He is a couple of months old, still a little stupid. It can grow into a full format, it will be great. No, it is also excellent, I hope, another, more qualitative challenger will appear on his wreckage.
Source: https://habr.com/ru/post/278793/
All Articles