i want use odata , benefits http caching. i've settled on rule "one entity has 1 uri". there many ways how perform query 1 entity, lets product sku=123 (which pk):
/myservice.svc/product(123) or
/myservice.svc/product?$filter=sku eq 123 or even
/myservice.svc/product(123)?$filter=sku eq 123 the obscure way how query product via title:
/myservice.svc/product?$filter=title eq 'some handy product' (lets expect query returns 1 entity - product 123)
my question is: what odata-way how respond kind of queries?
after research, last opinion is:
- let product(123) work is
- in case of $filter=sku eq 123 / id eq 123 respond http 302 , location header pointing product(123).
- in case of product(123)?$filter=sku eq 123 respond 400 (bad request), because silly. or maybe 302 redirect product(123)..
but last case?
product(123) -> should return single entity in response payload
product(123)?$filter=sku eq 123 -> doesn't make sense - filter supposed apply collections of entities, , product(123) identifies single entity (always). many odata services today ignore due behavior or server stacks, 400 acceptable since query option not apply.
product?$filter=sku eq 123 -> product identifies entity set, collection of entities (aka feed) should returned. though particular query happens identify single entity, feed single entity in required response.
product?$filter=title eq 'some handy product' -> same sku eq 123 in terms of expected response. though might identify single resource, not change fact entity set must still contain feed response.
you said wanted hold rule 1 entity has 1 url. in odata, 1 url identifies entity, though multiple urls give same information it. so, i'd argue ok. 1 url identifies resource called canonical url. product(123) canonical url. in, say, json payload, odata.id give canonical url of entity.
so these other queries seem reference same entity? in valid filter examples (the 3rd , 4th ones), path identifies collection indicated above. fact collection happens contain 1 entity irrelevant. path identifies resource still product(123). other urls can give give information entity without 'identifying' it. don't think you've broken you're statement in way.
to answer 3xx part of question: free respond request sort of redirect - part of http, , odata not change that. however, redirect not same shape original request bad server behavior. instance, product(123)?$filter=whatever identifies collection of product entities. redirect product(123) bad idea in opinion, since identifies single entity. response write out different! i'd surprised if existing odata clients handle that, , wouldn't expect new ones handle either.
what mean http caching? well, quite frankly, @ least in scenario's given, don't think should special.
Comments
Post a Comment