![iFixit Tears Down New M4 MacBook Air [Video]](https://www.iclarified.com/images/news/96717/96717/96717-640.jpg)
![Apple Officially Announces Return of 'Ted Lasso' for Fourth Season [Video]](https://www.iclarified.com/images/news/96710/96710/96710-640.jpg)
![9to5Rewards: Last chance to win a MacBook Pro from Chargeasap [Giveaway]](https://i0.wp.com/9to5mac.com/wp-content/uploads/sites/6/2024/10/M4-MacBook-Pro-doesnt-tempt-me-because-Apple-Silicon-Macs-are-almost-too-good.jpg?resize=1200%2C628&quality=82&strip=all&ssl=1)
![[The AI Show Episode 139]: The Government Knows AGI Is Coming, Superintelligence Strategy, OpenAI’s $20,000 Per Month Agents & Top 100 Gen AI Apps](https://www.marketingaiinstitute.com/hubfs/ep%20139%20cover-2.png)
![[The AI Show Episode 138]: Introducing GPT-4.5, Claude 3.7 Sonnet, Alexa+, Deep Research Now in ChatGPT Plus & How AI Is Disrupting Writing](https://www.marketingaiinstitute.com/hubfs/ep%20138%20cover.png)
.jpg?#)
.jpg?#)
Custom API Classification
I never knew there were API standards or protocols like REST. For over a decade i have used the same type of custom API because it "just worked" for me. I have used it for both Web and Game development when needing to interface with a server. Now that an application i have created might be moving into the "professional" space and may need to be accessed or understood by more than me or my applications, I'm a bit worried i don't know how to communicate what type it is or that what I created will cause issues in the future. What I have created is a PHP API system that takes commands and GET/POST data. I split my PHP files up into separate "mini" APIs that are specialized to certain types of data or functionality. For example one PHP file might handle user authentication while another might handle the creation/retrieving of orders in the database. I THINK i would have to classify my API as a RPC API from what i've been reading. Basically you make a call to api.webaddress.com/orders.php?cmd=getOrders with POST variables for username, session token, and maybe some for order number or customer ID, etc. The API then switch cases the command to verify it is a valid command and checks the username and session token if the requested information requires security. The API then returns a JSON object with a success boolean and any information that needs to be sent back to the client. I separated the functions into separate files thinking it made the API a bit more secure as you not only need to know the API address but the file name as well to probe the API and also to reduce the size and complexity of PHP code that the server has to process to hopefully speed up the API while reducing the load on the server. On my public web app there is a separate API system from my administration API as well to further separate the functions for security and performance. My public API currently has maybe 3 separate PHP mini APIs and my Admin side API has as many as 8. My main questions given this information are: Should i have consolidated all of the mini APIs into a single PHP file? Should i have created a single API manager PHP file that parses the information and then includes the required mini API php file into it's code? Did i create something that never should have been created? lol What type of API would this set up be most like when explaining it to people that need to interface with it in the future?
I never knew there were API standards or protocols like REST. For over a decade i have used the same type of custom API because it "just worked" for me. I have used it for both Web and Game development when needing to interface with a server. Now that an application i have created might be moving into the "professional" space and may need to be accessed or understood by more than me or my applications, I'm a bit worried i don't know how to communicate what type it is or that what I created will cause issues in the future.
What I have created is a PHP API system that takes commands and GET/POST data. I split my PHP files up into separate "mini" APIs that are specialized to certain types of data or functionality. For example one PHP file might handle user authentication while another might handle the creation/retrieving of orders in the database.
I THINK i would have to classify my API as a RPC API from what i've been reading. Basically you make a call to api.webaddress.com/orders.php?cmd=getOrders with POST variables for username, session token, and maybe some for order number or customer ID, etc. The API then switch cases the command to verify it is a valid command and checks the username and session token if the requested information requires security. The API then returns a JSON object with a success boolean and any information that needs to be sent back to the client.
I separated the functions into separate files thinking it made the API a bit more secure as you not only need to know the API address but the file name as well to probe the API and also to reduce the size and complexity of PHP code that the server has to process to hopefully speed up the API while reducing the load on the server.
On my public web app there is a separate API system from my administration API as well to further separate the functions for security and performance. My public API currently has maybe 3 separate PHP mini APIs and my Admin side API has as many as 8.
My main questions given this information are:
- Should i have consolidated all of the mini APIs into a single PHP file?
- Should i have created a single API manager PHP file that parses the information and then includes the required mini API php file into it's code?
- Did i create something that never should have been created? lol
- What type of API would this set up be most like when explaining it to people that need to interface with it in the future?
