New answers tagged

0

There are plenty of JSON serialization systems that are more than capable of handling mapping between field names that aren't suitable for use in the language they integrate with. In most cases, they aren't hard to use, and require only a little bit of extra effort. In an ideal world, you wouldn't have to, but if your API already uses dashes, changing it ...


1

JSON API is nice, but complex spec. Its implementation is also not easy, especially if you don't have good library implementing it. So it's mostly a question "is it worth it for our use case"? In my opinion, it's worth it if you have large and/or public API which needs to be stable, extensible, will be developed for years. JSON API provides reasonable ...


2

You can use anything as JSON keys, as long as it is valid UTF-8, doesn't contain zero code points, and it would be useful if you could represent the key as a string in the programming language of your choice. I might recommend not to use different Unicode representations of the same string (for example "Ä" written as one or two code points). Reading some ...


0

Would you like to be able to dynamically add new content and functionality to your client without having to change it? If you go with Json API (and actually leverage it), you can accomplish exactly that. Let's say v1 of your book resource looks like this links: { self: "/books/1" next: "/books/2" } author: { links: { ...


-1

I'm currently dealing with a SOAP API and it's corresponding WSDL. After looking over the JSON API specs. I get the impression that they are trying to be a WSDL equivalent for REST JSON servers. Like WSDLs, the JSON API is not the most readable in the world (although more readable than WSDLs,) but is meant to be parsed by tools that will then create the ...


0

I'm not interested in JSON, I'm interested in the objects that are created from JSON. Like in your example, turning plain JSON into objects is easy. How difficult is it for new developers? Mostly they are interested in the objects created. They can look at the code that turns JSON into objects, which is trivial. I looked at the JSON API spec, and I ...


2

I think two issues to consider are: (and you're referenced this above) - do you need to find child nodes ? In which case you perhaps want to avoid storing sizeable hierarchies and instead store the individual Foos such that they're immediately searchable. That may impact tree construction/retrieval times Do you want to move children between trees? If you ...


0

One drawback is that when you want to create a backend interface for your form setup, you need to understand howthe JSON data is being used and interpreted. Even with a simple database management tool like phpMyAdmin or MS SQL Management Console someone could easily understand how the form is structured and how to make a field required or copy a whole form. ...


0

PostgreSQL supports both JSON data type and GIN indexes out of the box so that will fly just fine with relational databases. You can also choose to model some of the fixed fields as normal columns and only use JSON for the dynamic fields. I would favor PostgreSQL over MongoDB especially if you also need proper ACID transactions and if your data fits on one ...


0

As far as I am concered. Mongo could index a document, but I am not sure if that index goes for "abitrary" records. One technology that comes to mind if we talk json documents would be elasticsearch. That was build for ... searching.



Top 50 recent answers are included