I have tried to use "rest/layers.json" to get all data,but only got the services have been published.
I thought it might be
"rest/workspaces/{workspaceName}/datastores/{datastoreName}/featuretypes.json" ,bu i always get the emty object.
it should look like:"rest/workspaces/{workspaceName}/datastores/{datastoreName}/data.json.
so,how to get the data list with a datastore exactly.
GeoServer REST services are only managing configuration, there is not data access. If you want to get data, use WFS, it's really simple, e.g.:
http://demo.geo-solutions.it/geoserver/wfs?service=WFS&version=1.0.0&request=GetFeature&typeName=topp:states&outputformat=application/json
Related
I'm currently building a pipeline using the purview atlas API to extract server guids, and from there, extract database guids, and so on and so forth until the column level. But don't see any API endpoints that allows me to extract all possible server guids from a collection? Is this possible?
This is not possible at this moment.
Could you please check this document to get list of guids:- Discovery - Query - REST API (Azure Purview) | Microsoft Docs
I am not sure if this could solve your problem, but here is what I do:
In my case, I need to extract the dictionary from Purview. To do that, i do the following:
pv glossary read
from that, i get a json with all the guid. Then,
pv glossary readDetailed --glossaryGuid= <<guids have found>>
I will just leve it here as a response just in case you can get anythig from this.
Thank you
I am working a project where I will be integrating GraphQL to a backend Express server. Currently, the server's structure is much like a MVC pattern structure.
Controllers folder
functions to query data from a MySQL database and return it.
ex: file named Car.js and in there are functions such as getAllCars() and getCar(id)
Routers folder
endpoints that call the functions in the controllers and returns it to caller
ex: endpoint GET /cars that will call getAllCars() and return it
I want to wrap GraphQL on top of this and was wondering what if the best way to do this. As far as I know, each GraphQL type has fields and resolvers and the resolver is the one that will get the data (please correct me if I'm wrong).
So I guess my question is...
If I want to wrap GraphQL on this, in the resolver, do I call the endpoint that will fetch me the data?
If I have a controllers folder that is already handling the data access/modification in the db, can I simply just call the controller function in the resolver and don't necessarily 'need any endpoints'?
I hope this makes sense, I am still very new to GraphQL and am very excited to work with it.
Thank you!
Please find my answers below
If I want to wrap GraphQL on this, in the resolver, do I call the endpoint that will fetch me the data?
The GraphQL should always be served from a single end point. It is the query that changes but the end point will always be the same.
If I have a controllers folder that is already handling the data access/modification in the db, can I simply just call the controller function in the resolver and don't necessarily 'need any endpoints'?
This is debatable. It is a good practice to always separate out the handling the data access/ modification outside the controller like in a service layer.
I'm looking for design pattern/library to combine multiple different endpoint to be visible as one.
Let's say I have 3 endpoints, each of them returns the same type of objects, of course objects are different and have unique id. I want to create an endpoint which calls all of them, combine results, filter & sort & page, then return results.
There can be many objects, so it could be good to have caching, to call those three endpoints only when something has changed (let's say I somehow know if I need to refresh cache).
I imagine there's a library which can connect multiple endpoint into one, cache results and deliver filter & sort & page. Some sort of, let's say, Spring repository: however data are not read from database, but from cache, which gathers them from REST endpoints.
I was looking at Gateway design pattern like Spring Gateway or Zuul Proxy, but it seems to be only a wrapper, no possibility process data.
Of course I can do such things manually:
create controller
call three endpoints (if needed to refresh)
fill cache
read data from cache sort, filter, page, and return them
but if I need to do that multiple times, I'm looking for library to do that.
You can implement the GatewayFilterFactory with aggregation and caching in Spring Cloud Gateway. But it looks like the creation of a controller.
I am working on a REST service and so far all the queries are retrieved using a GET request.
Right now we are using a sort of routing rule like this one:
API/Person/{id} GET
http://api.com/person/1
Now, what if I want to ask to the REST API "Give me a Person with FisrtName = 'Pippo'"
I have a complex DTO that I called PersonQueryDTO that can be sent to the REST method to interview the database using the query criterias.
Is this a good way to do it or should I build complex queries in a different way?
For me it's important to keep the REST principles.
If you want to stick with REST principles, then the way to do something like that is to supply additional parameters in the URL e.g.
GET API/Person?FirstName=SomeName
REST is all about identifying resources, API/Person identifies your collection of Person and the additional parameters are nothing but meta data which the service can use internally to determine what sort of result to return.
I have the basics of a REST service done, with "standard" list and GET/POST/PUT/DELETE verbs implemented around my nouns.
However, the client base I'm working with also wants to have more powerful operations. I'm using Mongo DB on the back-end, and it'd be easy to expose an "update" operation. This page describes how Mongo can do updates.
It'd be easy to write a page that takes a couple of JSON/XML/whatever arguments for the "criteria" and the "objNew" parts of the Mongo update function. Maybe I make a page like http://myserver.com/collection/update that takes a POST (or PUT?) request, with a request body that contains that data. Scrub the input for malicious querying and to enforce security, and we're done. Piece of cake.
My question is: what's the "best" way to expose this in a RESTful manner? Obviously, the approach I described above isn't kosher because "update" isn't a noun. This sort of thing seems much more suitable for a SOAP/RPC method, but the rest of the service is already using REST over HTTP, and I don't want users to have to make two different types of calls.
Thoughts?
Typically, I would handle this as:
url/collection
url/collection/item
GET collection: Returns a representation of the collection resource
GET collection/item: Returns a representation of the item resource
(optional URI params for content-types: json, xml, txt, etc)
POST collection/: Creates a new item (if via XML, I use XSD to validate)
PUT collection/item: Update an existing item
DELETE collection/item: Delete an existing item
Does that help?
Since as you're aware it isn't a good fit for REST, you're just going to have to do your best and invent a standard to make it work. Mongo's update functionality is so far removed from REST, I'd actually allow PUTs on the collection. Ignore the parameters in my examples, I haven't thought too hard about them.
PUT collection?set={field:value}
PUT collection?pop={field:1}
Or:
PUT collection/pop?field=1