4 ms·
Counter to some of the other comments (thus far), I'm on board with this as a method. With the correct header variables, such as Accept-Content, we can settle
by mattowen_uk 6y ago
Counter to some of the other comments (thus far), I'm on board with this as a method.
With the correct header variables, such as Accept-Content, we can settle on nice standardised database querying over the web. Think beyond web pages, and think about proper client-server applications, where the developer doesn't have to re-invent the wheel, or use a framework that may not be in use or supported a few years down the line.
Imagine using curl to do a HTTP SEARCH and piping the response directly into your app or other command line tools. No time wasted developing or installing supporting libraries - it just works.
Edit: Now I think about it, maybe SEARCH is the wrong name. Using SQL as a [bad] example, it would be odd to use HTTP SEARCH to do an insert or update query.
- montroser 6y agoBut the method wouldn't actually _do_ anything in your app by itself. If you would want to pipe a SEARCH request's query somewhere directly, that would be up to you in your app to listen for that request method at some url endpoint and send the request body to some data store. Some people do this sort of thing with sending GraphQL queries to GET routes which may do some validation and then send the query back through. Is there a downside to using GET here?
- jcubic 6y agoWhen I've seen this method for the first time I immediately thought about GraphQL. For this usage SEARCH is good name. Also SEARCH was suppose to be case when you don't mutate data, so SQL insert and update is not good usage of it. You should use POST for that.