Александр

Аналогично, ничего не нашел, только вот доработка админки opencart'a у меня проблем не вызвала. Писал под себя несколько модулей и расширял базовые функции. Код там вполне нормальный. Архитектура MVC.

Разработчики Opencart вроде как считают что их код сверхпонятный и в документации не нуждается. Я тоже пытался найти подробную документацию, но в итоге понял что кроме гугла и изучения их собственного кода найти мало что получится.

Статей хватает, можете конечно написать, но врят-ли что-то-новое выйдет.

Структуру методов, что и как должно возвращать лучше обсудите с iOS разработчиком, который будет потом имплеменить это дело. Если такого нету — максимально разбейте все на атомарные операции, упростите взаимодействие, прикиньте сами какие методы могут понадобиться (представьте что вы пишете API не для кого-то, а, например, для странички, которая через AJAX все выдерает).

По поводу реализации — банальная сериализация вместо рендринга, больше отличий нету. Есть куча готовых компонентов которые хорошо подходят для сериализации туда и обратно. Свой такой компонент тоже пишется достаточно быстро.

Для авторизации обычно применяют токен-авторизацию. Мол при авторизации пользователю выдается уникальный токен (рандомная строка), который он потом шлет в заголовках каждый раз при обращении к методам API. Это можно сделать как отдельную прослойку.

Я не видел ни одного RESTfull API для серьезных приложений, тобиш да, оно то REST но не полностью, так что заморачиваться тут не стоит. Достаточно просто обрабатывать какие-то базовые заголовки и GET/POST запросы. GET для выборок — тобиш данные в базе при запросе не меняются, разве что какие счетчики, а POST для создания записей в базе (по феншую результат работы функции должен возвращаться только HTTP заголовки, среди которых есть GET запрос с URI нового объекта, но на практике никто не париться и возвращает весь объект или его часть).

Можно конечно воспользоваться SOAP апишками, но по опыту скажу что оно годно только при разработке оочень простых API, и толку от него мало. Если клиентом, конечно, будет приложение написанное на C# .NET — тогда смело SOAP и только SOAP, вам по сути разницы в реализации (имеется в виде по времени) минимум, а разработчику клиента будет намного проще. А вот на iOS с SOAP все достаточно печально.

В первую очередь почитай про принципы работы REST (ну или Soap, смотря что использовать будешь). Ну и опытом хабратоварищей можно воспользоваться:
Раз
Два

Если внутри сервера с одной софтинки на другую то тут несколько вариантов
1. файлы (пишем, открываем другой, читаем, используем)
2. бд (тоже самое)
3. сессия (почти тоже самое только еще проще)
4. memcached (почти тоже самое, неплохой вариант)

cookies не костыль, собственно для этого они и придуманы (сессия — дальнейшее развитие идеи)

А у вас противоречие в условиях, по-моему:
Вариант с GET не подходит, ибо данные явно висят в url противоречит но через обычную ссылку их не передашь. Либо данные висят в урл, либо через обычную ссылку (без дополнительных скриптов на клиентской стороне) их не передать. Третьего не дано.

Может устроит вариант:
1. На исходной странице обычная GET ссылка на промежуточную страницу с данными в URL, нажимаем
2. Сервер принимает данные, пишет их в сессию и делает редирект на целевую страницу без данных в URL
3. Целевая страница достаёт данные из сессии и тут же сессию очищает.

Если пользователь не смотрит куда ведёт ссылка (или его браузер не показывает), то данные в URL мелькнут в адресной строке очень не надолго на современном ненагруженном компе и быстром инете.

Опять же если стоит задача скрыть от пользователя данные полностью, то это не реально, мониторить трафик умеют сейчас все популярные браузеры. Можно усложнить жизнь шифруя данные, но только усложнить. А для защиты от случайной утечке данных по сценарию типа «ломщик увидел секретный url, запомнил и дома его ввёл» моего сценария, имхо, достаточно.

Вопрос поставлен не совсем корректно, т.к. может быть 2 трактовки:

1. Если речь идет о веб-скриптах, которые выполняются последовательно, то чем вам не нравится сессия? В данном случае это не костыль — она именно для этого и придумана. Если не нравится непосредственно стандартная реализация, то можно взять собственную (принципиально аналогичную): генерировать ID клиента (сессии) и передавать его через get/post/cookie (по вкусу), а уже сами данные хранить либо в файлах, либо в базе данных, и получать с помощью этого идентификатора в качестве ассоциативного ключа.

Непосредственно данные через куки, гет и пост передавать естественно в данном случае не стоит: эти вещи всегда можно подделать, т.к. они идут через клиента. Это можно назвать костылем :)

================
2. Если же речь идет о выполняющихся одновременно 2 шелл-скриптах, т.е. межпроцессное взаимодействие (IPC), то тут можно использовать разные более или менее системно-зависимых вариантов. От стандартных механизмов IPC: семафоры, сообщения, шаред блок памяти, до специфичных вещей вроде именованного пайпа или сокета; или же аналогичных п.1 вещей (база данных/файлы).

Тоже костыль, но без js, ajax, cookies, sessions итд, как вы и просили.

Сценарий вызывает другой сценарий по URL любым удобный для вас способом, передавай параметре в хоть GET который пользователю, все равно, не будет виден.

Простейший вариант (если включен allow_url_fopen):
$answer = file_get_contents('http://www.example.com/script2.php?param1=A&param2=B');

При желании можно даже что-то вернуть и это использовать.

Привет!
По поводу поиска: вам нужно искать HCPC (Home Theatre Personal Computer)-компьютер, выполняющий функции домашнего кинотеатра.
Мы строим медиа-сервер и всё, что нам нужно это, что бы ресурсов железа хватало на воспроизведение медиа-файлов. Win2003 имеет много ненужный служб, а нас интересует только работа с медиа и загрузкой файлов. Что бы всё это дело работа на максимальных от оборудования возможностях, нужно грамотно распределить ресурсы системы (ну и вообще, что бы ничего лишнего не было). Могу порекомендовать, как уже было подмечено *nix систему:
-mythbuntu — это линуксовая ОС, полностью состоит из Ubuntu. Ubuntu весьма не сложна в понимании (имеет граф. интерфейс) и думаю не чуть не труднее win систем.
Установив её вы можете сверху прикрутить xbmc, который позволит вам приятно пользоваться вашей медиа библиотекой, если будете пользоваться непосредственно медиа-сервером. Поддерживает пульты ДУ, если организуете на системе приём ИК сигнала или д.р.
Для того, что бы файлы на сервере появлялись, предложу 2 способа — их уже озвучили и могу подсказать только какой совт на мой взгляд оказался приятен для юзабельности:
1-й способ
Установка торрент-клиента azureus и установки к нему плагина WebUI. Он даст возможность обращаться к торрент-клиент удалённо через http. (поднять http сервер можете с помощью Apache). Получаем: скачали нужный торрент файл на удалённой машине, зашли на ваш торрент-клиент на веб интерфейс и через него закинули торрент-файл на сервер. Вам сразу же будет показан список загружаемых и загруженных файлов.
2-й способ
Можно воспользоваться vsftpd. Фтп сервер (можете выбрать другой). Настраиваем соответственно с нужными вам правами. Пример: одна папка для torennt файлов с возможностю записи, ну а вторую downloads на чтение для скачки. Далее устанавливаем rtorrent. Консольный торрент-клиент с приятной возможностью проверки папки на наличие файла с определённым форматом (*.torrent). Получаем: заходим по через ftp клиент с удалённой машины на наш сервер и кидаем в папку torrents файл bla-bla.torrent, в то время rtorrent уже начнёт закачивать файл в указанную вам дирректорию (к примеру нашу downloads).
Сам проделывал оба способа. Удачи!

Боюсь напороться на минусы, но честно скажу, что не прочёл ни одной специализированной книги кроме «Философия Java» (Эккель), я предпочитаю больше времени уделять чтению статей, уроков, мануалов и исходников. Последние принесли больше всего пользы.