I have been using the module https://www.npmjs.com/package/json-schema and have the schemas for validations in JSONSchema6.I have read that JSONSchema6 is backward compatible with JSONSchema4. Is there any utility code to convert JSONSchema6 to JSONSchema4? I need this as AWS API Gateway supports only JSONSchema4 (as per https://docs.aws.amazon.com/apigateway/latest/developerguide/models-mappings.html#models-mappings-models)
It's not difficult to do by hand, or write a program to do so, as the differences between the two versions are straightforward. They are itemized here: https://json-schema.org/specification.html (scroll down for the links to differences between 4 and 6 for the two specification documents).
Related
I need to understand the difference between
- message pack
- protocol buffers
- JSON
Without having jumped in deeply into the matter I'd say the following:
All three are data formats that help you serialize information in a structured form so you can easily exchange it between software components (for example client and server).
While I'm not too familiar with the other two, JSON is currently a quasi-standard due to the fact that it is practically built into JavaScript - it's not a coincidence it is called JavaScript Object Notation. The other two seem to require additional libraries on both ends to create the required format.
So when to use which? Use JSON for REST services, for example if you want to publish your API or need different clients to access it. JSON seems to have the broadest acceptance.
We're creating a web service and we'd like 2 things:
- to be JSON based
- to be REST-full - how much so, we haven't decided
We've already implemented custom APIs but now we'd like to follow some standards, since at some point it gets a little crazy to remember all the rules, all the exceptions, and all the undocumented parts that the creator also forgot.
Are any of you using some standards that you've found useful? Or At least, what are some alternatives?
So far I know of jsonapi and HAL.
These don't seem to be good enough though, since what we'd optimaly like is to be able to:
+ define, expose and update entities and relations between them
+ define, expose and invoke operations
+ small numbers of requests are preferable, at least where it "makes sense" (i'll leave that as a blank check)
[EDIT]
Apparently, there's OData too: http://www.odata.org/
Are any of you using some standards that you've found useful? Or At least, what are some alternatives?
Between your own question and the comments most of the big names have been mentioned. I just like to also add JSON Hyper Schema:
"JSON Schema is a JSON based format for defining the structure of JSON data. This document specifies hyperlink- and hypermedia-related keywords of JSON Schema."
http://json-schema.org/latest/json-schema-hypermedia.html
It's an extension to JSON schema and fulfils a very similar role to the others mentioned above.
I've been using json-hal for a while and like it a lot, but I'm increasingly drawn to the JSON Schema family of schemas which also handle data model definition and validation. These schemas are also the basis of the excellent Swagger REST API standard:
http://swagger.io/specification/
Hope this helps.
http://localhost/v1/documents?format=json&uri=%2Fdocs%2F1234.json
It looks like this URL is giving us XML instead of JSON which is causing some issues.
I believe this started happening once we upgraded to Marklogic 8.
You can see we are specifying json which seems right based on this:
https://docs.marklogic.com/REST/GET/v1/documents
How do I get this to return JSON?
In MarkLogic 6 and 7, JSON documents were represented internally as XML, that being the standard hierarchical document format supported in those versions. Access through the REST API was transparently JSON for read & write, it was just different under the hood. In MarkLogic 8, JSON is a native format, so the transformations went away. MarkLogic's Support team has an article about how JSON is handled in versions 6, 7, and 8 -- that should help you.
You can do effectively the same using MLCP as well, with the additional benefit that you can repeat the migration easier, optionally against a different target environment or database, and/or add extra tweaks if you like. Export your database files with archive mode, and reimport with this transform:
https://github.com/marklogic/demo-cat/blob/develop/src/transform/to-json.xqy
We did this for an internal migration of demo-cat from MarkLogic 7 to 8. The steps we took are documented here:
https://github.com/marklogic/demo-cat/blob/develop/migration.md
HTH!
We are going to be moving some data around that will have some standard fields as well as some key value pairs which will vary between data items. Obviously we could code something in JSON or XML to do this and write our own marshalling/unmarshalling code however I was hoping for a standards based solution that has some or all of the following:
Marshalling/unmarshalling for SharePoint lists/.Net
Marshalling/unmarshalling for Java
Service definitions and semantics for operating on the data across an integration boundary
Security semantics
We are currently looking at the OData protocol to perform this task: http://www.odata.org/
Presumably you've made your decision long ago now, but for anyone else who ends up here, and is perhaps interested in something at a lower level than OData, here's what I'm using for C# to Java data interchange:
Google Protocol buffers as the interchange format:
https://developers.google.com/protocol-buffers/
Marc Gravell's protobuf-net at the C# end:
http://code.google.com/p/protobuf-net/
A program called called protostuff at the Java end:
http://code.google.com/p/protostuff/
(I prefer protostuff to the official Google Java implementation of protocol buffers due to Google's implementation being based on the Java objects being immutable.)
Actually, I'm not using pure protocol buffers as the interchange format - I prefix the data with the name of the (outermost) class being transmitted. This makes the data self-identifying for deserializing at the other end.
I am designing a class library designed to solve a wide scope of problems. One thing about this library is that it will be usable by several different languages and environments natively. For example, there will be a C++ version written entirely in C++, a .NET version written in C# and a Java version written in Java, without any dependencies on each other... as opposed to writing the core library in C++ and simply providing .NET and Java bindings to it.
The library in each of its different forms sets out to solve a different but sometimes very similar set of problems. For example, there might be many classes whose members will be functionally identical in each language, and there will also be many classes that will be present in only one or two language-versions of the library, but not the others. Take a class or struct representing a program's version number. .NET already has such as class (System.Version) so I would not include it in my .NET version but the C++ and Java libraries would provide one.
The problem I am facing is that for classes which will exist in most or all versions of the library, the documentation will remain relatively the same (obviously). The brief text for both the C++ and Java version for a Version struct would be something like "Represents a software version number in the form major.minor.build.revision"... as would the detailed class description, and all the members' documentation, etc. As you know, .NET, Java and C++ all have their own documentation syntax. Is there any way I can attempt to consolidate documentation in a language-neutral way (WITHOUT writing the documentation separately from the source code - e.g. manual documentation as opposed to generating it using doxygen/sandcastle/javadoc) or am I stuck copying and pasting the same text into the source files of each version?
I was having the same issues and decided there were just two options for me:
Using the same documentation generator in all languages. If you use doxygen (or ROBODoc, or whatever) for all of them, you would have just one doc syntax for all languages. This means that you have to break with language-specific conventions, though.
Write your own doc parser. Which is hard work, especially for a language with quite complex syntactic rules (as C++.)
We are currently using doxygen for such projects.