JSON Schema seems to support ISO times, dates, date-times, and even durations (see documentation), but I can't find anyway to support ISO time ranges.
I could use regex (which JSON Schema does support) but then I wouldn't be able to check if the start and end points of the interval were actually valid dates/times (e.g. 2022-13-04 there is no 13th month). How should I proceed? Do I just have to accept any string and do the validation in the JSON consuming application?
String formats aren't validated by default; instead they're merely annotations - information for the application to act upon.
However, many implementations do have validation that can be enabled. Many also support custom formats, though you'd likely need to provide the logic yourself.
An alternative approach is to split the time range into its start and end components and validate those independently. Then all your app has to do is verify that start < end.
Related
According to the docs about scalars in GraphQL there is no support for binary data up to now.
According to above page it is possible to define own Types.
How could you implement a binary scalar in GraphQL?
I came here looking for an answer and after some reflection I got to the following conclusion, it is not a direct answer to the question but I think it is related and important to consider. You shouldn't implement a binary scalar in GraphQL.
I think for small images the encode as base64 solution will work great but for bigger files it goes against the design philosophy of GraphQL about efficient data transfer, so a better alternative would be to have those files somewhere else, like a CDN and just use the reference in GraphQL.
Size matters, for small queries it could make no difference but for big complex queries it could be a big performance problem.
The documentation seems to hint that custom types would still somehow boil down to default types:
In most GraphQL service implementations, there is also a way to specify custom scalar types. For example, we could define a Date type.
Then it's up to our implementation to define how that type should be serialized, deserialized, and validated. For example, you could specify that the Date type should always be serialized into an integer timestamp, and your client should know to expect that format for any date fields
The first thing that pops to mind in this case will be a base64-encoded string. Depending on your language of choice SO likely will have a sample serialisation/deserialisation routines.
You can but have to use default data-type to create a new one. For audio, video or images you can easily convert it into base64 and pass them as a string but in that, you have to keep in mind the length of the data as it's not stored in the buffer.
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 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 want to test my application and I need to generate different load. Application is SUPL RRLP protocol parser, I have ASN.1 specification for this protocol. Packets have a lot of optional fields and number of varians may be over billion - I can't go through all the options manually. I want to automate it.
The first way to generate packets automatically, the other way is to create a lot different value assignments sets and encode each into binary format.
I found some tools, for example libtasn and Asn1Editor, but the first one can't parse existing ASN.1 spec file; the second one can't encode packets by specification.
I'm afraid to create thousandth ASN.1 parser because I can introduce errors in test process.
I hoped it's easy to find something existing, but... I'm capitulating.
Maybe, someone faced with the same problem on stackowerflow and found the solution? Or know something to recommend. I'll thank you.
Please try going to https://asn1.io/asn1playground/ and try your specification there. You can ask it to generate a sample value for a given ASN.1 type. You can encode it and edit either the encoded (hex) data, or decoded values to create additional values.
You can also download a free trial of the OSS ASN.1 Tools from http://www.oss.com/asn1/products/asn1-download.html which includes OSS ASN.1 Studio. This also allows you to generate (and modify) sample values for a given ASN.1 type.
Note that these don't generate thousands of different test values for you automatically, but will parse valid value notation and encode the values for you if you are able to generate valid ASN.1 value notation.
I am currently working on Rest API using Openrasta.
In this i am passing a date in JSON object to server side e.g. "/Date(1316802600000)/" for date (24/09/2011) which is standard format for sending date. But when I am receiving this on server side this date gets decreased by 1 day(23/09/2011). So each time I send a date across it gets decreased by 1.
Please suggest me some solution for this and let me know if I am making some mistake.
That doesn't sound quite like a problem that has to do much with OpenRasta. It may well be a JsonhDataContractSerializer issue, either that or one of your machines has timezone information but your code doesn't assign those correctly (say, truncating it or not using DateTimeOffset or whatever other reason).
Please post some of the code from your client, that may help in diagnosing your issue.
The JsonDataContractSerializer DateTime parsing can be very frustrating, especially when dealing with timezones. You might want to look at writing your own json codec that wraps the Json.NET serializer. The DateTime parsing is much more robust and can handle a variety of different DateTime formats.
Here is an example:
http://gist.github.com/BobReid/8960146#file-gistfile1-cs