我应该如何将数组从iOS传递到PHP以便正确存储（并返回）？

Question

I know this is a loaded question, but I think what I'm doing right now is probably the wrong way to go about things, so I'd like some input as to what is best practice.

Currently I have an array of actors. Let's say NSArray *actors in Objective-C. I want to pass this up to my PHP page for storage.

Right now I pass this up on HTTP POST by turning the array into a string such as this:

&actors=Joe Allen*Dave Smith*Mary Johnson*Alice Burg?movietitle=Runner

When it gets to PHP I'm then passing it to MySQL via a Stored Procedure call like this:

CALL Add_Movie(movietitle, actors);

And then in my sproc is where I 'explode' the actors by * to save them in the correct table. I do the reverse to get the actors back. It's gotten even trickier for me when I've wanted to separate first/last names.

Anyway, this seems really hacky to me. What's best practice for an array transfer over HTTP to SQL storage and back?

Answer 1

1. Pick an established serialization format, don't try to roll your own.
   • Established formats have pre-written libraries to handle things like encoding complex types and encapsulating/escaping strings/data.
2. Pick a serialization format that is well-defined and supported by both ends, that is IOS/ObjC and PHP.
   • You don't want to waste time writing new libraries to implement unsupported formats.
3. Don't store serialized data in an RDBMS, particularly MySQL.
   • Storage, access, indexing, etc all become difficult or impossible to do or do well.
   • If you're simply looking for a key-value store there are much better options than MySQL.

That said, there are two standout candidate formats:

• JSON: The lingua franca of the modern internet. Simple, lightweight, flexible, and damn-near everything understands it.
• XML: JSON's bloated uncle. Clunky, verbose, and generally a big pain in the ass; but if you want to impose typing, structure, and other such things on your data exchange format you could do worse than XML.

In the big picture what you've described sounds like the exact case for defining an REST API.