Web catalog

Below is a list of the existing web endpoints along with notes regarding their current state of use and proposed future development.

Part of the purpose for documenting them here is to consider future development needs as we move to upgrading from PHP 5.6 to PHP 7.x (a move which is necessary before the end of the year as all updates, including critical security issues, ceases for PHP 5.6 on 31st December 2018).

Endpoint	Purpose	Current state	Future plans
/order	Emailed to clients to enable them to pay for orders presents details of the user's order will find multiple unpaid order based on client ID and request payment for all if found	Still required (approx. 10% of all payments are made through this endpoint.)	Migrate to use the FileMaker DataAPI
/process	Second step in the payment process. Presents an accordion with Summary of the job details (exact details depends on the number of jobs being paid) Card details form Card billing address form	Still required	Migrate to use the FileMaker DataAPI
/3D	Optional 3D secure step in payment process	Still required	Migrate to use the FileMaker DataAPI
/internal	Used internally to take payments over the phone (money bag?).	Unknown - If this is still used, then what are payments recorded as MOTO?	Unknwon
/particle	Seems to have two functions send a notification email if a smoke detector is activated (presume called by some IoT detector?) creates an entry in both FileMaker and a MySQL table each time a door status changes. (again presume IoT switch?)	Unknown	Unknown (though note that the current code is not PHP 7.x compatible)
/postcode	Interact with Postcode Anywhere	Obsolete. Replaced with getAddress() called directly from within FM	No further action
/webform	Receives orders from the website to add to FileMaker	Used constantly and a critical component in the business system.	Migrate to use the FileMaker DataAPI. Consider rebuilding into a more modern API endpoint. The current version was built in early 2011 intended to be a 'drop-in' replacement for direct integration with the FileMaker XML done by SilkStream to provide better error handling and feedback to the remote system. As a consequence of this the data structure and the method of communication is decidely 'unique' and would benefit from complete rework. Note however that this will require changes on the web-end as well, so it may be better to rebuild an identical endpoint with modern coding.
/history	Generates XML responses with details about a client including their details, orders and delivery addresses. The original developer documentation provides details of this functionality.	Unknown. I don't believe this is used any longer as the current website holds its own user order history?	Unknown. If the same (or similar) functionality is required then it will need to be rebuilt to use the FileMaker DataAPI
/media	Locates image files in the 'numbers' folders and converts them to thumbnails for web display. See the original developer documentation for the /history endpoint for further details	As above	As above
/admin	Two purposes here used to deploy changes to the web code from version control used to register the DataGuard plugin	I don't think this is required. Presuming that we're able to move to hosting all PHP code on Linux then Ansible would be used to replace the deployment functionality and I don't believe that the DataGuard? plugin is used any longer?	Obsolete?
/webfleet	Interacts with the TomTom WebFleet API. There is also an associated set of command line tools associated with WebFleet.	Obsolete?	Obsolete?