I need to set my HTSQL server to act as a JSON API server, returning JSON-formatted output by default, not only when a query is followed by /:json. Is there a way to do this?
Reason: I need to send queries that are formulated by software that automatically places parameters (?foo='bar'&baz='moo') at the end of the URL, but HTSQL only recognizes an output format specifier like /:json when it comes at the absolute end of the URL, after the parameters. I don't know a way to build URLs like that without tedious and error-prone direct manipulation of the entire URL.
In other words, HTSQL demands that URLS look like
/mytable?col1='val1'&col2='val2'/:json
but I can't put the /:json after the parameters, so I'm looking for a way to have /:json be automatically implied.
The easiest way to do this is to submit the desired format with the Accept HTTP header. For example, Accept: x-htsql/json should give you JSON output.
You can also change the default output format, but it's rather tedious: You need to create an HTSQL addon and override htsql.core.fmt.emit.EmitDefault extension. Perhaps, you can bypass creating an addon by hot-patching this class.
Related
I came across an unusual URL structure on a site. It looked like this:
https://www.agilealliance.org/glossary/xp/#q=~(infinite~false~filters~(postType~(~'post~'aa_book~'aa_event_session~'aa_experience_report)~tags~(~'xp))~searchTerm~'~sort~false~sortDirection~'asc~page~1)
It seems the category, pagination and sort options of a widget on the page injects and reads through these values. Does this format for storing data in the URL have a name, or is this an esoteric format someone made?
What's the purpose of doing this over using regular GET params, or at least using a more conventional format after the fragment?
If you inspect the URL carefully, you'll see that the parameters you describe are placed after the fragment (#), meaning they're not sent to the server but used by the client instead.
In this case, the client (JavaScript) builds them into something like an ElasticSearch query that's then POSTed to the server, in order to update listing you see on your screen.
Should a WebDAV server support query strings?
I have not found a clear statement about this in RFC 4918.
Background is as follows:
I have a WebDAV server where the path in the URL is mapped quasi 1:1 to the path to the resource in the file system. I.e. to get to the resource I need to know the path, something like this:
Variant 1:
http://<webdavserver>:<port>/folder1/subfolder1/anotherfolder/resource.txt
Now I have another client that doesn't know the path, but only two Ids (RepositoryId and DocumentId), but these also uniquely identify the resource. By searching for the two ids, the WebDAV server can also find the resource and return it.
Until now, this was solved in such a way that instead of the path in the URL, the two IDs were specified as a query string, i.e. something like this:
Variant 2:
http://<webdavserver>:<port>/?repoId=123&docId=456
Somehow this feels wrong ...
Well, actually the identifcation via the two ids is just an alternative representation to the path, isn't it? So something like this should work too:
Variant 3:
http://<webdavserver>:<port>/<repoId>/<docId>
http://<webdavserver>:<port>/123/456
This feels more "WebDAV-like" ...
I would only need to be able to distinguish on the server side which of the two URL representations is arriving there, path or ID.
Possibly via a header, something like
X-ResourcePath: Path | Id (Default would be Path)
What do you think?
Should I stay with variant 2, or rather switch to variant 3, or ...? (I have to reimplement it anyway, so "Do not change a running system" would not be a valid argument :-))
IMHO: it really doesn't matter. There's no prohibition to mix query params into WebDAV URI trees. You just need to make sure that the clients that you support will work with this.
(I would advise against moving identifying data into custom request header fields; this is what the URI is for).
When I implemented a WebDAV server I was primarily interested in supporting existing clients and I found that most of them did not support query strings in any way (namely Microsoft Office)
I ended up using the following format which seems to work for all clients:
protocol://server/id/title.extension
Hi I am attempting to initiate a query to my backend on Kinvey which is backed by a MongoDB. They require passing URL parameters as such:
?query={"firstName":"James"}
I have tried every imaginable way of setting up these parameters in PAW but either get a success response with no filtering of the data or an error message of URL not supported when I try using a Raw Query String.
I have ran the query using their (Kinvey) backend API interface and it works fine in filtering the results so the problem definitely lies within PAW. I am currently using version 3.0.9. Any suggestions or is this just a bug that needs to be fixed?
Thanks!
I've just tried this setup in Paw and I have a few recommendations:
Paw will URL-encode the chars { and " as you can see if you open the HTTP preview in the bottom panel
Trying to send a similar query via Chrome (to test with another app to make sure Paw behaves correctly), I see that the query is URL encoded (try this query https://echo.paw.cloud/?query={"firstName":"James"} you'll see that the browser actually URL-encodes the characters { and " when sending. So the behavior is the same with Paw.
I don't think these two chars ({ and ") are valid HTTP if they are not URL-encoded, so I'm sure your server is expecting them encoded anyway
Testing this exact query in Paw, works for me, so please try these exact steps: go to URL Params, in the first column enter query and {"firstName":"James"} in the second column. Then using the HTTP preview mentioned above, make sure Paw is sending the request you're expecting.
Lastly, it's more like a tip, but as your value is JSON, I recommend that you use the JSON dynamic value to generate the JSON. It will be visually better for you, and will make sure you send valid JSON. For that, right click on the value field, and select Values > JSON. Here's some example:
I've installed the Swagger Importer, which is just great. It saved a lot of setup time. It also enumerated all of our APIs optional parameters, which is also good because I don't have to reference docs; however, I don't want GET and POST requests to send the params when I haven't explicitly set the values. Is there a way to configure PAW to not send URL Params when they have no value? One option is to just duplicate an item and then prune the list, but it seems reasonable that there should be a way to simply ignore items that aren't set.
For example:
Don't GET:
http://domain.com/api/v1/users?maxResultCount=&isActive=true
(because maxResultCount is optional and not set)
Instead, do GET:
http://domain.com/api/v1/users?isActive=true
The current release, Paw Version 3.0.7 (Retail) now provides checkboxes on URL parameters.
I need to use Fiddler to modify the POST fields sent by a browser. I know I can do that using the Fiddler UI but I want to create a script to do it automatically.
I need to insert the code inside the OnBeforeRequest method and I know I can use regular expressions to parse the POST fields but maybe there is something already available to do it like some sort of object POST with all the current fields, e.g: POST["field1"], POST["field2"], etc.
So...is it possible or do I have to do it manually?
Thanks!
Fiddler itself does not contain a script-accessible POST body parser, which means you'd either need to import one, write one, or use string processing to accomplish this task.