Study Abroad Schema#320
Conversation
|
@NathanP9000 , I put some review in your schema. In general, it's good overall it'd be better if you could somehow condense all of those variables into less fields but still maintain the information to our end users. You don't need to aim to capture almost all the fields from the API you found, because I think it's too nested & complicated that only the people working with that API understands what each field is about. |
|
Ok, I will do my best to condense further. |
…o develop Retrieving latest develop branch to resolve any merge conflicts and stay up to date.
|
@mikehquan19 I have made it more concise. |
|
|
||
| // Program Schema | ||
| type Program struct { | ||
| Id int `json:"programId"` |
There was a problem hiding this comment.
Id here should be Mongo-generated. We wouldn't use the id given by the 3rd party API, which means we should use primitive.ObjectID.
| } | ||
|
|
||
| type BrochureSection struct { | ||
| Id int `json:"sectionId"` |
There was a problem hiding this comment.
Same thing for ID here
|
I simplified the schema more. Also I think I'm missing the key for this MONGODB_URI: ${{ secrets.MONGODB_URI }}. Where can I get it? |
2 participants
I made a schema based on the response of the following API endpoint:
https://utdallas-ea.terradotta.com/models/services/REST/index.cfm?endpoint=/v3/program/10064/brochure.
My goal was to capture most of the variables.
A few points:
I saw there are typically two program types. The difference between the two are the structures. I focused on making a schema for the non OIE programs. However, the OIE programs are a subset of this type is what I determined at first glance. I will go back to double check.
It will be easiest to see how to adjust the schema while implementing the scraper.