How to define and store data structure properties in a database - json

I'm working on a PHP web app with a Postgres backend. The app uses a variety of APIs and want to be able to add/edit the API endpoints used by the system dynamically.
I'm planning to handle variations in the API request URLs with replacement codes, for example: http://api.com/?key=%%api_key%%&user_id=%%user_id%%
The part I don't have a plan for is how to define and store the "shape" of the returned API data. For example, let's say I want to get a user's comments from different APIs. The structure of the data will likely differ from one to another. Even if they are all json data (vs. XML), the property(s) I care about will be located in different places. Is there an established way to do this?
I'm considering a text field with a json "map" to the location of the properties:
{
"user": {
"comments" : %%HERE%%
}
}
Presumably my app would parse this, and loop through it to find the indicated location and then use it to find the data in the corresponding location in the response data. But I'm not exactly how to do it or if this is even the best way. Any suggestions are welcome.
Thinking this through a bit more, I realize that an alternative approach would be to store some kind of algorithm to finding the data. Is there a precedent for this? I briefly considered the idea of storing raw PHP code that could be executed to parse the data, but this feels very wrong and potentially dangerous/insecure.

JOLT may be helpful. It's for transforming JSON to JSON, much like XSLT for XML. You could write a spec for each new api, which would transform the data into a uniform format for your app to read.

Related

Is it a good practice to use models in GetX Flutter to parse JSON data?

Hello there I am creating an application in Flutter and I am receiving JSON response from the API and I know that we need to parse the response to use in the Flutter app but I found that if we use the normal way as:
jsonData['key'] to get and show the data because this way you can handle any kind of response easily but when I am using the models way then I am facing a lot of issues in which the data structure and data types included.
and I think the model only provides an object structure in which you can access data as an object way like jsonData.key instead of the jsonData['key'] this is only my thinking you can correct me if I am wrong here.
I just want to know that if I am using a non-model way then will it affect my app or not?
models are not resiliant. Your code will always break if the api is modified.
Use an Object is a good practice because helps to take advantage of the strong typed language. This allows you to have a better debug process, catch potential error during writing time (and in compilation time). And this is independent of the state management package that you choose.
Firstly, this has nothing to do with getX. Parsing json into models is much cleaner. You can compare two objects but how do you compare two jsons?
And if you need to create an instance of the object, how would you do so without a model? How would you pass it to another class or a function? I think the answers to this questions will solve your dilemma.

What is the difference between MessagePack, Protobuf and JSON ? Can anyone tell me which one to use when

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.

Protocol Buffers vs XML/JSON for data entry outside of programming effort

I would love to use protocol buffers, but I am not sure if they fit my use case. Here it is:
I have a Quiz app. This requires a bunch of data, like categories, questions, a list of answers (and which ones are correct). I do not want to be responsible for entering this data - I would prefer to pass it off to a non-programmer to serialize all this data for me, in either XML or JSON. Then my app would just read in the data file.
Does Google's Protocol Buffers fit my use case? Or should I stick to a more traditional format like XML or JSON?
I think not: Protobuf is a binary format. So then you would need to support a text format like XML or JSON and Protobuf.
Also it does not seem you would benefit from Protobufs better berformance at all.

Application Input Specification: Drawing input data of method

Does anyone know a good way to to draw the exact structure of input data for a method? In my case I have to specify the correct input data for a server application. The server gets an http post with data. Because this data is a very complex json data structure, I want to draw this, so next developer can easily check the drawing and is able to understand, what data is needed for the http post. It would be nice if I can also draw http headers mark data as mandatory or nice to have.
I dont need a data flow diagramm or sth. like that. What I need is a drawing, how to build a valid json for the server method.
Please if anyone have an idea, just answer or comment this question, even if you just have ideas for buzz words, I can google myself.
In order to describe data structure consider (1) using the UML class diagram with multiplicities and ownership and "named association ends". Kirill Fakhroutdinov's examples uml-diagrams.org: Online Shopping and uml-diagrams.org: Sentinel HASP Licensing Domain illustrate what your drawing might look like.
As you need to specifically describe json structure then (2) Google: "json schema" to see how others approached the same problem.
Personally, besides providing the UML diagram I'd (3) consider writing a TypeScript definition file which actually can describe json structure including simple types, nested structures, optional parts etc. and moreover the next developer can validate examples of data structures (unit tests) against the definition by writing a simple TypeScript script and trying to compile it

Custom jena-json writer

I'm creating a web apllication and i want to load a json file to a visualization library. the thing is the json file needs to be in a certain format.
I'm using jena to get data in a json file that is in the TALIS format. How can i get the data writen in a custom format?Is it easier to first get them in talis and then transform them or get them in the desired form from the beginning?
I'd appreciate every possible help!
You don't say how you are serving your data to the client-side JavaScript application. I'm going to take a guess, and assume you are using Jena Fuseki to serve the data. If that's not a correct guess, you'll need to update the question to be more precise about your setup.
I don't think that Fuseki currently supports pluggable writers. So your best solution would be to apply a transformation in the client-side JavaScript to turn the JSON you get from the server into the format that's needed by the visualisation library. I've done this myself in a number of rich-client applications that consume RDF data. I usually find that I would need to apply client-side transform code in any case - often it's not just a difference in the format of the JSON, but also that you need to project some slice or aggregation of the data that's just easier to express in JavaScript rather than in SPARQL or equivalent.