2 posts tagged with "JSightExplained"

We are pleased to announce that we have released the API sharing function in cloud with a unique link as part of JSight Online Editor release 4.0. This feature is a great addition to the ability to export documentation in a single HTML file. You may now choose whether to download the documentation as HTML or store it in the cloud using a unique URL.

Sharing documents via a link will provide you with three fantastic benefits:

1. Quickly share and discuss an API description with a colleague.
2. Store API documentation in the JSight cloud.
3. View the entire history of document modifications. (You can always revert to any previous version of the API by simply decreasing the version number in the link. You can also easily find the most recent API version (more on that below).

Furthermore, there is no need to register anywhere to share via the link, and it is absolutely free.

How to use sharing effectively? There are a great many options, for example:

1. You can quickly design an API on the fly in a team, exchanging links with drafts with each other.
2. You can save all references to all your APIs in Confluence and always have access to the most recent versions of the documentation.
3. You can send a link to the client so that they always have access to the latest version of the API.

See how it works by following the unique API example link: https://editor.jsight.io/r/g6X2ajV/3

Sharing API instructions​

How to share documentation for the new API​

Sharing is done as follows:

1. Describe your API.
2. Press the “Share” button (top right).
3. In the window that appears, copy the unique link to this API.

You can now share this link with anyone, and be sure that the content of the link will never change.

How to update a previously shared API​

If you want to change the content of the link, then you need to create a new version of the API. It is done as follows:

1. Open an existing API link.
2. Make changes to the API description.
3. Press the “Share” button (top right).
4. Select “Update API” (under the “Share” button).
5. In the window that opens, copy the new permanent link. The only difference between the new and original links is the last digit, which represents the serial number of the API version. For example, if your API was saved with the link https://editor.jsight.io/r/qjxZ46a/1, then when you update this API, the new link will be https://editor.jsight.io/r/aL9pnjZ/2 (the last digit has changed from 1 to 2 – this is the version number).

This way you can create as many versions of your API as you want, and each will have its own unique link.

How to check the latest API version​

If you don’t know which API version is the most recent, then you can open the link in your browser without specifying the version, that is, without the last digit. For example, instead of the link https://editor.jsight.io/r/qjxZ46a/2, open the link https://editor.jsight.io/r/qjxZ46a/ (I deleted the number 2 at the end), and the system will automatically redirect you to the latest saved version of your API.

P.S. We are currently working on creating convenient social snippets. This will allow you to immediately see the title and other important parameters of the sent API in the chat when sending a unique link.

There is no more difficult choice than choosing between two equally good options.

We had to make hundreds of such decisions when developing the JSight language. Making a decision entails more than just choosing between two alternatives. It's not so much about the decision, as about the criteria for making decisions. Firstly, you need to understand why the existing decision criteria do not help you choose the right option. Then, you need to modify these criteria. After that, making the decision itself is no longer difficult.

Today we are going to share about one of such cases.

In most data structures, certain fields are mandatory while others are optional. This needs to be somehow marked in the data schema. In our case, there were two possible solutions: add either a rule required or a rule optional to the language:

{
  "id": 123     // {required: true}
  "name": "Tom" // {required: false}
}

Or this way:

{
  "id": 123     // {optional: false}
  "name": "Tom" // {optional: true}
}

The second question following the first is what should be the default value: required: true or required: false? And accordingly in the case of optional, optional: true or optional: false? When I see a property in an example of valid data, it intuitively seems to me that this property “should be”, unless otherwise stated. This means that by default, required: true or optional: false is correct. Then we have the following options:

{
  "id": 123
  "name": "Tom" // {required: false}
}

Or this way:

{
  "id": 123
  "name": "Tom" // {optional: true}
}

Which option do you prefer? Please write in the comments to this post, we are interested!

After comparing both options, we decided to rely on this criteria: which at first glance is perceived as faster and more in line with intuition?

The brain is used to interpret information in the simplest way. When we see the word required..., our initial assumption is that this property is required, since that is what the word required means. Then, reading the rule till the end required: false, we experience cognitive dissonance. We initially assumed that the field is required, but it turns out that required: false.

There is no cognitive dissonance in the case of optional: true. We see the word optional... and we automatically assume that this property is optional. Then we read the rule till the end optional: true and find confirmation of our initial thought.

So, considering how quickly the schema is intuitively perceived, optional fits better than required. However, another strong criteria works in favor of required: this word is more familiar to us, it is used, for example, in JSON-Schema, OpenAPI, RAML.

What is more important: convenience or habit? After long debates, we concluded that since we were creating a completely new language, convenience is more important, therefore we went with optional. Time will tell whether we were right or not.