What are the options for passing data to PHP? [closed] - php

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
With minimal "real" programming experience, I am working on a project that integrates a FileMaker Pro solution, which I have already built, with a native iOS application using FileMaker Server's PHP API. The iOS application is for iPhone and is written in Swift.
We are trying to understand the most efficient ways to approach some scenarios, particularly in writing data back to the server. Let's use the simple example of an address book. When a user navigates to a contact record, he/she can select a field, edit then save it's contents.
While we have already implemented a number of functions that write data to the server, they have all been relatively simple (like scanning a barcode, sending a php request that triggers a script in FM Server and then presenting the result to the client). It seems like, in the case of a contact record with many fields, that sending the value of each field as a variable, some of which may be paragraphs or photos, through a standard PHP URL inefficient and bulky.
For those unfamiliar with the FileMaker PHP API, below is some sample code to demonstrate the process of updating a specific contact record. The sample code does the following:
Sets parameters passed from the client as variables.
Defines the layout on which the code should be executed (FM PHP API works on layouts, not tables like SQL)
Finds a record and updates the fields.
Sample Code:
<?php
require_once 'Filemaker.php';
//connect to db
$fm = new FileMaker();
$fm->setProperty('database', 'fmDbName');
$fm->setProperty('hostspec', '123.45.67.89');
$fm->setProperty('username', 'user');
$fm->setProperty('password', 'password');
//define layout on which to process
$layout = 'php_contacts';
//define variables passed from client
$contactId = $_GET['contactId'];
$first = $_GET['firstName'];
$last = $_GET['lastName'];
$mobile = $_GET['mobile'];
$office = $_GET['office'];
$note = $_GET['note'];
//Find the contact which is being updated
$find = $fm->newFindCommand($layout);
$find->addFindCriterion('contactId', $contactId);
//execute the find
$results = $find->execute();
//check for error
if (FileMaker::isError($result)) {
echo " Error: ".$results." ";
exit;
}
//declare the record being updated
$record = $results->getFirstRecord();
//update the fields
$record->setField('firstName', $first);
$record->setField('lastName', $last);
$record->setField('mobile', $mobile);
$record->setField('office', $office);
$record->setField('note', $note);
?>
The challenge we are facing is not how to implement a particular approach, rather, the challenge is understanding what the options are in the first place and any best practices that go along with them.
For example, is sending the variables from the client to PHP as an array or dictionary a better practice than sending them as independent variables in the URL? What are some other options for neatly pushing data from multiple fields in a native application to the PHP server?
Thanks!

Answer 1

I'm pretty sure PHP basically works with HTTP requests, that is basically POST and GET.
The structures you send should be defined by what you need, there is no perfect solution.
You should check how HTTP requests work:
http://www.w3schools.com/tags/ref_httpmethods.asp

Answer 2

$_GET is much slower than $_POST from my understanding. You should send POST requests to the server from your application which will transfer strings. Sending raw images over the Internet can easily lead to distortion and missing data. In order to send images as strings you would use Base-64 encoding. That means you'll convert the image binary to an encoding scheme which returns a string. You can send this string to the server or the application for decoding. (Note: You can use Base-64 encoded images as URLs, which may come in handy.)
I don't believe there's a better way to send data between a server and client aside from using either a POST message or raw JSON if you can do that. Swift and Objective-C have a class named NSJSONSerialization which you can use to convert JSON returned from a PHP script for use later in your application.
From your server you can simply create an empty array in a variable at the beginning of the script for later use then append information to that array as it becomes available (If you have an image on your server you'll want to Base-64 encode it then append the string to the array only after the Base-64 encoding completes). At the end of the script -- when you have all of the data you want to send to the application appended to that array -- you can write echo json_encode($thatArray) to send the array back to the application as JSON. Of course, that means you'll want this to be an associative array from the beginning, because you'll have key and value pairs.
I'd rely on that method to fetch information from the server and flip it around (create a Dictionary in the Swift application then use NSJSONSerialization.JSONObjectWithData(data: NSData, options: NSJSONReadingOptions, error: NSErrorPointer) to convert the Dictionary to JSON. Then create a request which will send that JSON to the server via a POST request. Of course, your PHP script would use json_decode($_POST['thatJSONFromTheApplication'])) for the application to send JSON to the server.
That's what I've done to allow my application and server to work together. If you read this and you have a better idea, do share!

Answer 3

So there are a couple of things you could or should do.
Should do:
Move credentials out of the document
Move your database connection information out of your php code and into a configuration file stored outside of the server document root, i.e. if your doc root is at:
/var/www/myapp/public/
You could store your configuration file at:
/var/www/myapp/config/
That way if php somehow fails and returns as text vs php code, your credentials are not exposed. You could do this in many ways, but the easiest I've seen is to define them as constants. e.g.:
// File config.php
define('FM_DATABASE', 'fmdbname');
define('FM_HOSTSPEC', '123.45.67.89');
define('FM_USERNAME', 'user');
define('FM_PASSWORD', 'password);
and require the config file in your code and use the constants in your connection object:
$fm = new FileMaker(FM_DATABASE, FM_HOSTSPEC, FM_USERNAME, FM_PASSWORD);
Never dump the entire result if it's an error
You're not doing this in your code, but it's a good thing to know if you're dealing with the FileMaker PHP API. The Error Result object that is returned if your runs into a snag will contain your connection credentials. I have no idea why this is so, but it is. Never dump the entire object to the client because you'll be exposing those credentials as part of the dump.
FileMaker's Error object extends the Pear Error Object, so if you end up wanting to pass back information on an error that was encountered you can use any of the pear error methods.
Use the connection object to test for errors
The FileMaker API code is pretty out of date when it comes to php. the static method FileMaker::isError is actually not defined as static in the API code. This means unless you supress the deprecated messages on your web server you'll have the web server barking at you about it. The thing is, you've already created an instance of the FileMaker object so you can use it to check if your result is an error:
if($fm->isError($result)){ // this won't produce the deprecated warning.
...
That said, you'll probably see a bunch of other errors because of other deprecated code in the api :P
Could do:
Cache the record id in your client app
Right now you're performing a find for a record, updating it's fields, and committing it. This emulates the FileMaker experience, but because you're editing the data via the php interface you may be able to short cut it a bit.
If your client application (the swift app) knows the record id for the record that it's updating already then you could use the newEditCommand to update the record instead. The edit command uses the FileMaker internal record id (i.e. the id that FileMaker gives the record, not the id from your user-added primary key) to determine which record to update. Here's an example of how you'd use it:
$editQuery = $fm->newEditCommand('my_layout', $recordId);
$editQuery->setField('Status', $newStatus);
$editResult = $editQuery->execute();
The advantage of doing this is less processing time for FileMaker Server. You're not asking the server to find the record so you can edit it, you're telling it what record to edit.
Depending on how the business logic flows through your apps this may not be an option, but if you could store the record id on the client side it may help make the communication a bit snappier.
Handle the updates in batches
It looks like you're already doing this, but be sure to send the data in a batch vs one field at a time. I would agree with Arcrammer's comments about using POST instead of GET as POST is the intended method for sending data to the server.
Those are my suggestions on your code. I would also suggest digging around in the API code. I find that looking over the objects and there methods answered a lot of questions for me that the documentation and tutorials that FileMaker provides for the API did not.
Good luck!