all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||
|
|
|
Blue
|
|
|||
|
|||
|
|
|
Notes:
|
|
Brainstorming notes between Brandon and an intern dealing with the adilas API: Notes from a brainstorming session on the adilas API (application programming interface). Brandon and an intern went through the code on the first round and then had a discussion about ways to improve things and help to standardize processes. - We would like to offer 3 data exchange formats. They would be JSON (java script object notation), WDDX (web distributed data exchange) and eventually standard XML (extensible mark-up language). - All API calls will be funneled through a single page called adilas_api_calls.cfm. - Currently we have both FORM fields and objects that get passed in. Our plan is to move towards objects. - As we transition from basic FORM field submission, we will need to alter the flow and order of things. - Eventually we would love for the process to be mostly database driven vs. customer code or special include files… Ideally we might need a mix. We could use the database for standard operations and then use the database plus custom includes for any custom work. Think about a fully automated way of getting a mix of both worlds. - We need to build out the documentation and the database for the API. Help people! - Setup a searchable sub section of the API. It would also be cool if we could categorize and even visually display API functions and methods. Use the adilas interactive map of the GPS (global positioning system) core interface to help organize and display options. - As part of the API, we would like to setup a 3 step testing environment to help with testing. Think of a virtual playground of sorts. The 3 steps would be: o Prep it – a form that allows preset options and input. o Convert it – this would format the data and show what the request would look like. And the… o Run it – show the results and what that would look like. - As a side note, it could be fun to allow both test and live data to be submitted. It might be cool if the developers could really see things in action and then mimic those actions in their own projects. - On a permissions and settings level, we want to help our users, clients, customer, and outside developers. Basically, the system will have to have a number of options to help it be dynamic and flexible. - To list a few of the options, we talked about: users, corporation (worlds), windows and doors (access), usage, limits, passwords, and security issues. We even talked about certain things that would not be allowed – rules of the game. - We determined that we need controls on the universe level, the world level (corporations), and on the who (users), what (permission and methods), when (optional times and dates), and where (IP addresses and domains) levels. - While talking about security, the intern mentioned about checking the existing list of black listed IP addresses and deny access to those without even checking the data. - Every method or API call would need a password. - We want to be able to track usage and history of who, what, when, where these API calls are used. As a note, the history may need to be added somewhere towards the top of a call or just before it gets returned. - Make sure and run the API over full SSL (secure socket layer). |