REST Медиа тип взрыва

Вы можете использовать экземпляры объектов, а не классы. Если вам нужен глобальный символ, вы можете использовать глобальную переменную. Поскольку в PHP они довольно громоздки, можно обернуть их функцией. Например: [

class ClassA {
  function call() {
    return $this->inner();
  }
  function inner() {
    return "Class A";
  }   
}
function ClassA() {
  static $instance;
  return $instance ? $instance : new ClassA();
}

class ClassB extends ClassA {
  function inner() {
    return "Class B";
  }
}
function ClassB() {
  static $instance;
  return $instance ? $instance : new ClassB();
}

echo "<p>Class A = " . ClassA()->call();
echo "<p>Class B = " . ClassB()->call();

] Но лучше вообще избегать глобальных символов; Причина, по которой он хорошо работает в Ruby / Rails, заключается в том, что Ruby на самом деле не имеет статического состояния, в отличие от PHP. Класс может быть повторно привязан и добавлен во время выполнения, что позволяет легко расширять структуру. В PHP классы всегда являются окончательными, поэтому обращение к ним в коде приложения является очень сильной степенью связи.

и используйте язык схемы, чтобы указать, какие из элементов могут содержаться.

Другими словами, такой язык, как xsd, может позволить вам ввести свой тип мультимедиа для поддержки одного из нескольких корневых элементов. Нет ничего предосудительного в том, что application / vnd.acme.humanresources + xml описывает XML-документ, который может принимать либо корневой элемент, либо его.

Итак, чтобы ответить на ваш вопрос, создайте как можно меньше типов мультимедиа, вопрос, будет ли то, что вы помещаете в документацию типа носителя, понятно и реализуемо для разработчика.

Вы используете тип носителя для передачи деталей ваших данных, которые должны храниться в самом представлении. Таким образом, у вас может быть только один тип носителя, скажем, «application / xml», и тогда ваши XML-представления будут выглядеть так:

<collection-of-collections>
    <collection-of-items>
        <item>
        </item>
        <item>
        </item>
    </collection-of-items>
    <collection-of-items>
        <item>
        </item>
        <item>
        </item>
    </collection-of-items>
</collection-of-collections>

Если вас беспокоит отправка слишком большого количества данных, замените JSON на XML. Еще один способ сэкономить на записанных и прочитанных байтах - использовать кодировку gzip, которая сокращает объем данных примерно на 60-70%. Если у вас нет потребности в сверхвысокой производительности, вам подойдет один из этих подходов. (Для повышения производительности вы можете использовать очень краткие строки, созданные вручную, или даже перейти к пользовательскому двоичному протоколу TCP / IP.)

Изменить Одна из ваших проблем заключается в следующем:

грубое [представление] означает, что в конечном итоге я буду передавать ненужные данные по сети, когда на самом деле клиенту нужно только прочитать или записать один атрибут элемента.

В любой веб-службе существует довольно много накладные расходы при отправке сообщений (каждый HTTP-запрос может стоить несколько сотен байтов для начальной строки и заголовков запроса, а также для каждого HTTP-ответа, как в в этом примере ). В общем, вы хотите, чтобы имел менее детализированные представления. Таким образом, вы должны написать своему клиенту, чтобы он запрашивал эти более крупные представления, а затем кэшировал их в некоторой удобной структуре данных в памяти, где ваша программа могла бы считывать данные из них много раз (но обязательно соблюдайте дату истечения срока действия HTTP, установленную вашим сервером). При записи данных на сервер, обычно вы комбинируете набор изменений в вашей структуре данных в памяти, а затем отправляете обновления как один HTTP-запрос PUT на сервер.

Вам следует взять копию [Richardson and Ruby] RESTful Web Services , которая является поистине отличной книгой о том, как проектировать веб-службы REST, и объясняет вещи намного яснее, чем я. Если вы работаете на Java, я настоятельно рекомендую фреймворк RESTlet , который очень точно моделирует концепции REST. Также может быть полезна диссертация Роя Филдинга USC , определяющая принципы REST.

это действительно отличная книга о том, как разрабатывать веб-службы REST, которая объясняет вещи гораздо яснее, чем я. Если вы работаете на Java, я настоятельно рекомендую фреймворк RESTlet , который очень точно моделирует концепции REST. Также может быть полезна диссертация Роя Филдинга USC , определяющая принципы REST.

это действительно отличная книга о том, как разрабатывать веб-службы REST, которая объясняет вещи гораздо яснее, чем я. Если вы работаете на Java, я настоятельно рекомендую фреймворк RESTlet , который очень точно моделирует концепции REST. Также может быть полезна диссертация Роя Филдинга USC , определяющая принципы REST.

Если вы не собираетесь регистрировать эти типы носителей, вам следует выбрать один из существующих типов mime вместо того, чтобы пытаться создавать свои собственные форматы. Как упоминает Джим, application / xml или text / xml или application / json работает для большей части того, что передается в дизайне REST.

В ответ Даррелу здесь Полный текст сообщения Роя . Разве вы не пытаетесь определять типизированные ресурсы, создавая свои собственные типы mime?

Суреш, почему HTTP + POX не является Restful?

Я думаю, что наконец получил разъяснение, которое я искал по вышеуказанному вопросу от Иана Презентация Робинсона и подумал, что мне стоит поделиться ею здесь.

Недавно я наткнулся на утверждение « тип мультимедиа для помощи в настройке движка гипермедиа, схема для структуры » в записи блога автора ] Джим Уэббер . Затем я нашел эту презентацию Яна Робинсона из Thoughtworks. Эта презентация - одна из лучших, с которыми мне приходилось сталкиваться, она дает очень четкое понимание ролей и обязанностей типов мультимедиа и языков схем (вся презентация - удовольствие, и я настоятельно рекомендую всем). Особенно обратите внимание на слайды с заголовком «Вы выбрали приложение / xml, вы выбрали st rd». и «Пользовательские типы носителей». Ян ясно объясняет различные роли схем и типов носителей. Вкратце, это мой вывод из презентации Иэна:

Описание типа мультимедиа включает модель обработки, которая идентифицирует элементы управления гипермедиа и определяет, какие методы применимы для ресурсов этого типа. Определение элементов управления гипермедиа означает «Как мы определяем ссылки?» в XHTML, ссылки идентифицируются на основе тегов, и RDF имеет для них разную семантику. Следующее, что помогает определить типы носителей, - какие методы применимы для ресурсов данного типа носителей? Хорошим примером является спецификация ATOM (application / atom + xml), которая дает очень подробное описание элементов управления гипермедиа; они говорят нам, как определяется элемент ссылки? и что мы можем ожидать при разыменовании URI, чтобы он действительно что-то говорил о методах, которые мы можем ожидать от применения к ресурсу. Структурная информация представления ресурса является НЕ частью или НЕ , содержащейся в описании типа мультимедиа, но предоставляется как часть соответствующей схемы фактического представления i. Спецификация типа носителя не обязательно будет диктовать что-либо о структуре представления.

Так что это значит для нас? просто нам не нужен отдельный тип носителя для описания каждого ресурса, как описано выше в моем исходном вопросе. Нам нужен только один тип носителя для всего приложения. Это может быть совершенно новый настраиваемый тип носителя или настраиваемый тип носителя, который повторно использует существующие стандартные типы носителя или, что еще лучше, просто стандартный тип носителя, который можно повторно использовать без изменений в нашем приложении.

Надеюсь, это поможет.