I know that it is possible to display the value of a key that is part of a Map that was stored in hazelcast using REST.
Using curl this would be done this way:
curl -v -X GET http://127.0.0.1:5701/hazelcast/rest/maps/myMap/nameOfKeyInMap
But what if I don't know which keys were used ? Following REST principles I skipped the nameOfKeyInMap part of the URL and expected Hazelcast to return a list of keys. But it didn't.
Do you know a way to get at least a part of the keys used ? I use Hazelcast 3.4 and checked the manual but didn't find a solution
I want to use REST because I need to have people check the maps that don't have much more than a browser on their computers.
Related
I was wondering what others are doing to expose REST api endpoints with the datastore (using app engine standard). I want to use urlsafe keys but 1 - I'd rather not pass this data directly as it poses a security risk since app-engine to app-engine calls are exposed over a public ip, and 2 - the keys that are generated are very long and would not be great when multiple need to be passed as a query parameter to form a get request (and would probably exceed browser character limits).
I was thinking maybe using compression of some sort to compress the urlsafe keys which would solve both 1 and 2, but want to see if there is a better way to create REST endpoints. Or if some type of compression method is already baked into ndb?
Google uses HTTPS internally so I'm not sure you need to worry about it.
Also, you should probably design your app so that keys are not secret info and such that it is safe to expose them.
I use key IDs for my REST calls, which I believe are 12 digit numbers. That works as long as you know the entity type. If you need to specify the entity type, you could add another parameter to your API call.
I tried to leverage the solution described in this post using fiddler : How to change change Kibana saved search (Discover) with a REST request?
Also I had a look at: https://discuss.elastic.co/t/export-saved-objects-via-rest-api/72028/2
My problem is that even though the json returned by my get rest request has the right value for the number of definitions, it does not embed them all (only 10 out of 34 search definitions), is there like a index + count option for fetching all of them.
Ok just found a workaround, actually, I should have thought about that before...
Here is what I have done, basically listened to the queries from the browser using fiddler (using the https decrypt option) on:
Settings tab
Saved objects
Searches
It seems that there is a size parameter that I was not really aware of (like I said in my initial post, thought about an index + count / limit like in any db system)
POST my_kibana_url/elasticsearch/.kibana/visualization/_search?size=100 HTTP/1.1
{"query":{"match_all":{}}}
And look at the count value to check whether the sizes of all the requests accumulated is matching that number.
We need to restrict a MarkLogic search to the latest version of managed documents, using Marklogic's REST api. We're using MarkLogic 6.
Using straight xquery, you can use dls:documents-query() as an additional-query option (see
Is there any way to restrict marklogic search on specific version of the document).
But the REST api requires XML, not arbitrary xquery. You can turn ordinary cts queries into XML easily enough (execute <some-element>{cts:word-query("hello world")}</some-element> in QConsole).
If I try that with dls:documents-query() I get this:
<cts:properties-query xmlns:cts="http://marklogic.com/cts">
<cts:registered-query>
<cts:id>17524193535823153377</cts:id>
</cts:registered-query>
</cts:properties-query>
Apart from being less than totally transparent... how safe is that number? We'll need to put it in our query options, so it's not something we can regenerate every time we need it. I've looked on two different installations here and the the number's the same, but is it guaranteed to be the same, and will it ever change? On, for example, a MarkLogic upgrade?
Also, assuming the number is safe, will the registered-query always be there? The documentation says that registered queries may be cleared by the system at various times, but it's talking about user-defined registered queries, and I'm not sure how much of that applies to internal queries.
Is this even the right approach? If we can't do this we can always set up collections and restrict the search that way, but we'd rather use dls:documents-query if possible.
The number is a registered query id, and is deterministic. That is, it will be the same every time the query is registered. That behavior has been invariant across a couple of major releases, but is not guaranteed. And as you already know, the server can unregister a query at any time. If that happens, any query using that id will throw an XDMP-UNREGISTERED error. So it's best to regenerate the query when you need it, perhaps by calling dls:documents-query again. It's safest to do this in the same request as the subsequent search.
So I'd suggest extending the REST API with your own version of the search endpoint. Your new endpoint could add dls:documents-query to the input query. That way the registered query would be generated in the same request with the subsequent search. For ML6, http://docs.marklogic.com/6.0/guide/rest-dev/extensions explains how to do this.
The call to dls:documents-query() makes sure the query is actually registered (on the fly if necessary), but that won't work from REST api. You could extend the REST api with a custom extension as suggested by Mike, but you could also use the following:
cts:properties-query(
cts:and-not-query(
cts:element-value-query(
xs:QName("dls:latest"),
"true",
(),
0
),
cts:element-query(
xs:QName("dls:version-id"),
cts:and-query(())
)
)
)
That is the query that is registered by dls:documents-query(). Might not be future proof though, so check at each upgrade. You can find the definition of the function in /Modules/MarkLogic/dls.xqy
HTH!
I want to list all the keys stored in the memcached server.
I googled for the same, I got some python/php scripts that can list the same. I tested it but all went failed and none gave me full keys. I can see thousands of keys using telnet command
stats items
I used perl script that uses telnet to list keys, but that got failed too. I mean that script is listing keys but not all of them.
Do I need to reconfigure telnet ? Is there any other way ?
memcache does not provide an api to exhaustively list all keys. "stats items" is as good as it gets to list the first 1M of keys. More info here: http://www.darkcoding.net/software/memcached-list-all-keys/
Not sure if that helps you but redis (which could be considered a superset of memcache) provides a more comprehensive API for key listing and searching. You might want to give it a try.
It you use python-memcached, and would like to export all the items in memcache server, I summerized two methods to the problem in this question: Export all keys and values from memcached with python-memcache
How to get Best Practical's RT configuration (list of users, queues, possible values for status field, possible values for custom field) via its REST interface? Or may be there is some web page where this information can be easily parsed from? I found sources for REST interface in rt-3.8.7.tar.gz/rt-3.8.7/share/html/REST/1.0 but I know little of perl and don't understand how these scripts are executed and what they are doing.
Have you tried: http://wiki.bestpractical.com/view/REST