Я реализую настраиваемый контроллер в ASP.NET MVC и действительно хочу иметь возможность использовать двоеточие в URL-адресах, чтобы я мог идентифицировать имена классов и столбцов и их значения, например:
http://example.com/user:chaiguy
... но, видимо, ASP.NET или IIS не разрешают двоеточия в URL-адресах. Я сделал некоторые копания и, по-видимому, рассматривал проблему безопасности, но я использую MVC и обрабатываю все пути URL вручную (просто рассматривая их как строки) и не связывая их с файловой системой, поэтому я уверен, что это не применяется.
Я также слышал некоторые разговоры о внедрении пользовательского Http-обработчика или что-то в этом роде.
Любые мысли или идеи будут высоко оценены.
Er.... почему? Серьезно, зачем нарушать стандарты? - Рэндольфо
...
Я предлагаю, чтобы вы исследовали создание веб-службы. WCF - хорошая технология для этого, и он хорошо переносится в IIS.
Мне нравятся URL-адреса, а WCF слишком сложна для моих целей. Я хочу, чтобы он был совместим с url, например REST, но способен не только перемещаться по иерархиям, но и выполнять хорошо продуманные вещи. Проблема с /users/chaiguy заключается в том, что она интерпретирует иерархию там, где ее нет: в моей системе "пользователь" - это класс, это не папка. user: chaiguy означает экземпляр класса пользователя со значением "chaiguy", и это единый объект, который имеет потенциал наличия дочерних объектов. Так, например:
/user:chaiguy/name
... Я хотел бы отобразить имя этого объекта. Если бы я сделал это с помощью вашего метода, это выглядело бы так:
/users/chaiguy/name
Проблема в том, как вы знаете, что такое класс и какое значение? Его можно интерпретировать как
/users/chaiguy:name
в моей системе, и это не имеет смысла. Посмотри, что я получаю? Чтобы дать несколько более сложный пример, предположим, что мы хотим выбрать дочерний элемент пользователя из нескольких экземпляров. Таким образом, пользователь может иметь несколько адресов электронной почты. Чтобы выбрать один, мы можем использовать:
/user:chaiguy/email:[email protected]/
Таким образом, это фактически рекурсивно. Это не путь к файлу, он больше похож на XPath (или, может быть, похож на jQuery, основанный на том, что я немного знаю об этом). То есть, это скорее динамически оцениваемый выбор запроса, чем проводной путь к файлу. Он оценивается на сервере.
Не ошибитесь, я не строю типичный веб-сайт или даже веб-сервис здесь.
