Re: Feedback on draft-ietf-httpbis-safe-method-w-body-02

["Slik, David" <[e-mail]>]

>> The resource that a query method targets is often a representation of a
>> collection. As such, while technically correct, I would consider the
>> statement, "The payload returned in response to a QUERY cannot be
>> assumed to be a representation of the resource identified by the
>> effective request URI." to be a little strong. Perhaps, "The payload
>> returned in response to a QUERY*MAY*be a representation*other than*the
>> resource identified by the effective request URI."?
>
> Well, it will be something else most of the time. If it wasn't, we could
> just use GET, no?

Fair enough, as the above property (where the query response is the same media type as the default GET media type for the URI) is only true for some types of queries.

> "content" is the correct term as per
> <https://greenbytes.de/tech/webdav/draft-ietf-httpbis-semantics-19.html#content>.
> (But we could hyperlink that).

Guess I'm showing my 2616 age. :)

Thanks for the pointer to that draft. Nice to see all of the 723x RFCs, etc, being consolidated together.

>> Regarding, "It is important to note, however, that such conditions are
>> evaluated against the state of the target resource itself as opposed to
>> the collected results of the search operation.", when the target
>> resource is the collection, the conditions are evaluated against the
>> entire collection (not just against the resulting subset, as you
>> mention). This distinction may require additional elaboration.
>
> I don't see a contradiction here. Note that "collection" is something
> not defined in HTTP. If the target resource is a "collection", then yes,
> the condition is by definition evaluated against the state of that
> collection.

Agreed.

Queries involving a "collection" (being structured content, typically in XML or JSON, following a specific schema where multiple entities are stored) are a very common use case for query, so I'll re-read the draft and see there are any other suggestions around this use case that we may want to consider.

> I agree that more examples would be good. However, this would introduce
> a dependency on a draft that is likely to be finished farer in the
> future. Maybe there's a simpler-but-standardized JSON query language
> that we can use (optimally with a defined media type...).

Ah, I did not know that the timeline for draft-ietf-jsonpath-base was further out.

I will take an action item to draft another example based on something similar that is already approved.

Would you like me to open it as an issue in github, or send it to the mailing list for discussion first?

Thanks,

David Slik
Technical Director, Astra Platform
NetApp, Inc.