Это эквивалентно помещать что-то как часть пути и как параметр?

Question

Прямо сейчас у меня есть два способа выполнить (по-видимому) одно и то же в моем приложении. Я могу либо сделать мои URL-адреса похожими на это: https://something/product/shirt или https://something/product?q=shirt. В обоих случаях я могу извлечь из него то, что мне нужно, это рубашка.

Первый способ (с регулярным выражением):

class FirstHandler(BaseHandler): 
    def get(self, page_id): 
     target = page_id 

PAGE_RE = r'(/(?:[a-zA-Z0-9_-]+/?)*)' 
app = webapp2.WSGIApplication([('/something' + PAGE_RE, FirstHandler)], 
           debug=True) 

Второй способ, которым я могу справиться с ней с помощью параметра, который будет выглядеть следующим образом:

class SecondHandler(BaseHandler): 
    def get(self): 
     target = self.request.get('q') 

app = webapp2.WSGIApplication([('/something' SecondHandler)], 
           debug=True) 

Мой вопрос в том, эквивалентны ли эти методы? Это то же самое, если я делаю то или другое, или мне нужно принимать во внимание что-то еще?

Answer 1

Посмотрите на все запросы, которые вы ожидаете сделать, и определите, какие из них должны быть представлены уникальными конечными точками (/shirt) и которые позволят использовать один или несколько параметров. Вы можете комбинировать эти подходы, когда это необходимо.

Отсутствует штраф за исполнение или любое другое преимущество использования URL-адреса или параметров.Ключевыми факторами являются:

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

Например, /shirt может выглядеть как хорошая идея сейчас, но как только у вас есть тысячи видов продукции, это становится кошмаром для поддержания. Вместо этого вы можете использовать что-то вроде:

/product/?type=shirt&size=10&orderBy=price&results=20&offset=40 

Answer 2

app.yaml можете предварительно маршрут для вас (в другое приложение WSGI - даже с помощью dispatch.yaml «s, к различным модулей), на основе URL-адресов, но не на основе конкретных запросов к данному URL.

Итак, если вы определить ресурс, как /something/product/shirt, вы может в будущем «административном» (путем изменения app.yaml и, возможно, dispatch.yaml конфигурационных файлов, не Python код) предварительно маршрутные определенные продукты для различных приложений WSGI или даже модулей ; если вы идентифицируете его как /something/product?q=shirt, административная маршрутизация на основе конфигурационного файла будет использоваться только для одного приложения WSGI на основе только /something/product, а затем это будет до кода, обслуживающего это приложение для работы с частью запроса.

Итак, при прочих равных условиях вы можете использовать URL-адреса, чтобы сохранить гибкость маршрутизации в будущем. Части запроса ценны для таких вещей, как необязательные параметры и независимость от заказа - представьте, например, /something/product/shirt?fmt=json&size=xl, где fmt и size оба являются необязательными с некоторыми стандартными параметрами и могут необязательно выполняться в любом порядке, что было бы неприятным/сложным в отношении URL-адресов только в то время как с тривиальностью легко достичь запросов.

Но «синтаксис запроса» с одним обязательным параметром является (умеренным) «запахом дизайна API» - и не только в App Engine; в то время как App Engine имеет свои механизмы маршрутизации и диспетчеризации, они не особенно не соответствуют тому, что можно ожидать от других серверов.