Skip to content

Support for SEARCH http method #1306

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
lennygran opened this issue Jul 30, 2017 · 8 comments
Closed

Support for SEARCH http method #1306

lennygran opened this issue Jul 30, 2017 · 8 comments
Labels
http Supporting HTTP features and interactions

Comments

@lennygran
Copy link

The SEARCH http method is not supported by OpenAPI specification, although defined in few RFC, including https://tools.ietf.org/html/draft-snell-search-method-00#section-2. Although having limited use, this method is a perfect fit for getting a list of items using PII or any other secure filters. Use of GET is not possible because PII filters cannot be included to URL. The SEARCH allows to do so. Hence it would be a great enhancement.

@darrelmiller
Copy link
Member

I was hoping that ID would make it out of draft status but as it expired almost two years ago, I fear it might never make it. We do limit the allowed methods to the most common ones, because if we were to allow the full official list then we would have to add wacky ones like 'BASELINE-CONTROL' and 'REBIND'. https://www.iana.org/assignments/http-methods/http-methods.xhtml

Personally, I would be open to making it an open value, but I'm not sure that would fly with anyone else.

@lennygran
Copy link
Author

I fully understand your concern. Unfortunately relaying on the original RFC introduced SEARCH as part of WebDAV https://tools.ietf.org/search/rfc5323 might not be a better idea either as it defines too many dependencies on WebDAV schemas and flows.

I think it is a valuable method, it would be sad to "loose" such. There is no clear alternative to do a REST API for search with secure filter (provided within body). Often folks use POST, but it conflicts with "create", introducing ambiguity.

Would you be willing to open this topic for discussion with your team and community?

@webron
Copy link
Member

webron commented Jul 31, 2017

There was actually a discussion in #325. We ended up adding TRACE, but nothing else.

@deganmee
Copy link

deganmee commented Aug 1, 2017

I work in the same problem space - needing to search using data points that are PII or PHI. For this we POST to a /search endpoint. With some wordsmithing, it makes sense to use POST method. We consider that we are "creating" a search - possibly creating a cached result set of which we only return the first page. You can then use a cursor to GET /search/ the following pages of results.

@darrelmiller
Copy link
Member

POST doesn't mean create. It means none of the other HTTP methods were more suitable, so we had to fall back to POST. Create just happens to be one of the more common usages of POST.

@handrews
Copy link
Member

@darrelmiller @lennygran do either of you have any idea if anyone's started an IETF draft for an HTTP equivalent to CoAP's FETCH? Or know if there's a reason why that's not likely to work?

https://tools.ietf.org/html/rfc8132#section-1.1 (note that this even references the expired SEARCH draft as an inspiration)

@handrews
Copy link
Member

handrews commented Nov 2, 2018

@darrelmiller @webron @lennygran note that the SEARCH draft has been revived- the current draft is valid until March 23, 2019: https://tools.ietf.org/html/draft-snell-search-method-01

@handrews handrews added the http Supporting HTTP features and interactions label Jan 29, 2024
@handrews
Copy link
Member

Let's track this under issue #1747 which covers all HTTP methods and includes SEARCH in its list. Closing this in favor of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
http Supporting HTTP features and interactions
Projects
None yet
Development

No branches or pull requests

5 participants