Существует ли опубликованная многократно используемая объектная модель в Интернете - правильный «язык домена» / терминология для запроса http - PullRequest
0 голосов
/ 24 декабря 2009

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

Мне трудно найти правильные имена для моделирования игроков в запросе http в моем приложении на стороне сервера.

Например, протокол передачи гипертекста (RFC 2616) описывает части URL-адреса HTTP как:

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] 

Принимая во внимание, что RFC 1738 использует эту терминологию для определения частей URL:

An HTTP URL takes the form:
      http://<host>:<port>/<path>?<searchpart>

Допустим, я хочу показать объявление рядом с некоторым основным контентом на веб-странице , размещенной на моем исходном сервере,

Я бы хотел попросить дополнительный контент-сервер найти лучшее объявление, подходящее для основного контента и отобразить их вместе как ресурс , который является подается по URL.

Одна из моих самых больших проблем с поиском правильных слов, чтобы различать:

  • URL-адрес клиента (веб-адрес, который кто-то может ввести в панель браузера - т. Е. http://example.com/mydocument?page=2) (я называю этот каноническим URL в данный момент)
  • адрес-сервера-источника (адрес, по которому сервер шлюза обращается для получения страницы, т.е. http://originserver.example.co.uk/version2/mydocument?page=2)
  • фактический контент по каноническому URL (который постоянно меняется)
  • ревизия этого фактического контента по этому URL
  • имя вещи, которая определяет связь между URL-адресом и текущим контентом ( семантическая метка-заполнитель / или praps семантическая спецификация ) - т.е. http://example.com/mydocument означает «список книг, относящихся к хоккею»
  • страница 2 контента по каноническому URL
  • страница 2 содержимого, отображаемого приложением после применения фильтра
  • и т. Д. И т. П.

Я слышал, что есть книги, в которых определены языки, специфичные для предметной области, для различных отраслей.

и есть такие книги, как Шаблоны анализа Фаулера: многократно используемые модели объектов (которые я не читал).

Итак, мой вопрос:

Существуют ли какие-либо книги / веб-сайты / опубликованные модели, которые обобщают все спецификации w3c, лучшие практики, терминологию SEO и объединяют все это в удобную и удобную опубликованную объектную модель, которая может быть действительно вездесущим веб-приложения, которые я могу принять для своего веб-приложения?

В основном, что-то, чтобы сократить двусмысленность.

ссылки: RFC 1738 (http://www.ietf.org/rfc/rfc1738.txt) HTTP / 1.1 RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2)

Ответы [ 2 ]

0 голосов
/ 24 декабря 2009

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

Из того, что я понимаю по вашему вопросу, что касается URI / URL, все, что находится за номером хоста / номером порта, должно быть синтаксически правильным. Я думаю, вы спрашиваете, что является семантически правильным, и ответ, к сожалению, сводится к тому, что «все идет, пока синтаксис правильный». При работе со сторонними сайтами вы действительно должны брать то, что они вам дают, если только вы не имеете на них никакого влияния. Для вашего собственного сайта вы можете посмотреть, как URL-адреса форматируются людьми, использующими REST (в качестве предложения, другие, пожалуйста, включите это).

Сеть так долго была ковбойской страной дикого, дикого запада, что независимо от того, какие спецификации, если она не выдает ошибку, вам часто приходится терпеть лот рыхлых Несс с точки зрения семантики. Это только одна из причин, почему некоторые люди говорят о стране грез «семантической паутины».

0 голосов
/ 24 декабря 2009

Учитывая, что веб-протоколы расширяемы, полный язык невозможен.

...