How would JSON describe this API
We are constantly re using very similar code blocks when it comes to describing the API for the project we are working on.
I would like to describe our API's for all our projects using JSON. I am not good, however, at structuring well formed JSON.
We would need the following data:
1. Internal company name [ we have 2 ]
2. The project name
3. Client Info ( name, address, etc )
4. Project Info ( url, description, notes )
5. Api info
-- base url ( each project has one directory )
-- endpoint url ( /getUsers )
-- endpoint friendly name ( Get Users )
-- endpoint method ( post )
-- endpoint parameter type ( body, path, queryString )
-- endpoint parameters
name, type
I guess that would be it. I just want a catch all JSON that we can use to for an admin site we are making for the company, as well as to call upon for our projects.
Can anyone help me get going?
Thanks!
I would like to describe our API's for all our projects using JSON. I am not good, however, at structuring well formed JSON.
We would need the following data:
1. Internal company name [ we have 2 ]
2. The project name
3. Client Info ( name, address, etc )
4. Project Info ( url, description, notes )
5. Api info
-- base url ( each project has one directory )
-- endpoint url ( /getUsers )
-- endpoint friendly name ( Get Users )
-- endpoint method ( post )
-- endpoint parameter type ( body, path, queryString )
-- endpoint parameters
name, type
I guess that would be it. I just want a catch all JSON that we can use to for an admin site we are making for the company, as well as to call upon for our projects.
Can anyone help me get going?
Thanks!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I understood company name to be a single key with two possible values.
Just a note on nesting - it depends on how you are going to deal with the data.
If you need to send the Project info (for example) off to a separate process it might make sense to nest it and send off the child key - but if your data set is small there is no real benefit to doing this other than aesthetically it might look more pleasing. Ultimately it takes up more space and requires more complex addressing to get to values.
If all you are doing is using the data to run some process to generate some code then I don't see any advantage of nesting over single level declaration of values. If your value set grows to a point where there are a significant number of fields then nesting might help in terms of managing the data (visually) - other than that there is no benefit.
Just a note on nesting - it depends on how you are going to deal with the data.
If you need to send the Project info (for example) off to a separate process it might make sense to nest it and send off the child key - but if your data set is small there is no real benefit to doing this other than aesthetically it might look more pleasing. Ultimately it takes up more space and requires more complex addressing to get to values.
If all you are doing is using the data to run some process to generate some code then I don't see any advantage of nesting over single level declaration of values. If your value set grows to a point where there are a significant number of fields then nesting might help in terms of managing the data (visually) - other than that there is no benefit.
ASKER
Thanks guys. I made some good progress on this. Now, my next task, and you will most likely see a question in JS on this, will be...
how do I write a class ( or functions? ) to initialize a project, know what I mean? Well, that's another thread. Thank you both.
how do I write a class ( or functions? ) to initialize a project, know what I mean? Well, that's another thread. Thank you both.
What is wrong with just doing this
Open in new window