I have a REST service /accounts which returns all the accounts data (Number, Name).
Requirement :
Should Support the below search/filter pattern with any combination of "And" or "OR" rather than retruning the entire collection.
startsWith
endsWith
Contains
Question 1 : Are these below API design correct(RESTful) or any better way to do the same
e.g -
/accounts?name^My Account 123**or**number~ACC1234
(^"==> Starts with , "~"==> ends with)
/accounts?name^My Account 123**and**number~ACC1234
(^"==> Starts with "~"==> ends with)
/accounts?name$ACC123
($ ==> account collection contains ACC123)
Spring Controller:
Planning to get these Filter (Query Parameter) pattern as #RequestParam and have a Regex to parse the pattern and then apply & retrieve it from the data store. The downside is any new filter pattern would need a change in the Controller class.
Question 2: Is there any out of the box features available in Spring 3 to do search / filter from a collection?
Thanks!
From a design perspective, using Query parameters to specify search / filter parameters is fine. However, for more complex cases such as yours, I typically define a new end point, that only deals with searches.
As an example, if my logic for search is strictly "or" and "contains", I would define a book search as such:
GET /books/?author=john&keywords=how%20to%20use%20spring
Here, my API is strictly going to search for books where the author's name contains "john" and the words "how to use spring" appear in the content. The Search logic stays consistent, and the client has no flexibility.
In your case, if the client has the ability to specific their own search criteria, you need to build out a new end point, something like:
POST /books/search
And in the request body, post your own search criteria DSL like name^My Account 123**and**number~ACC1234
Related
Disclaimer: I couldn't come up with a better name for the question - but I'll try to explain what I'm trying to achieve.
Let's assume we have a client-server application with client-side internationalisation. At this moment it is out of the question to move all the internationalisation to the backend.
The backend service saves some tags in the database as strings. (e.g.: CAR)
The client of this service performs a GET, translates the tags and displays them in the view (e.g.: Car (en), Auto (es)).
Now we want to add some filters to a query based on the tags.
Everything works fine as long as we have a list of pre-defined tags that are mapped to the tags stored in database, but how would you implement a solution where a user can type in a text filter (in any language) and the backend to return the values matching with the "original" tag?
i.e.: type in auto, backend returns CAR.
I am developing an API in a microservice for Invoice entity that takes in input a list of Purchase Order Item (i.e. PO Item) identifiers for ex. PO# + productIdentifier together can be used to identify a POItem uniquely. The response of the API is the invoiced quantity of each PO Item.
Input Model -
input GetInvoicedQuantityForPOItemsRequest {
poItemIdentifierList : POItemIdentifierList
}
Structures
list POItemIdentifierList {
member : POItemIdentifier
}
structure POItemIdentifier {
purchaseOrderNumber : String,
productIdentifier : Long
}
Invoiced Quantity of a POItem = SUM of Quantity of Invoice Items created from that PO Item.
Note : A single PO can be used to create multiple Invoices. An Invoice can be created from multiple POs.
I am quite new to REST and so far we have been using RPC endpoints in our legacy service. But now i am building a new service where i am defining endpoints in REST format (for ex. CreateInvoice has been changed to POST /invoice) and I need some suggestions from Stack Overflow community what would be the right approach for defining the REST endpoint of this API or should we keep it in RPC format itself.
RPC endpoint for this API in legacy system : POST /getInvoicedQuantityForPOItems
Our first attempt on REST for this is : POST /invoice/items/invoicedQuantityForPOItems. But this URI does not look like a Noun it is a Verb.
this URI does not look like a Noun it is a Verb.
REST doesn't care what spelling conventions you use for your resource identifiers.
Example: this URI works exactly the same way that every other URI on the web works, even though "it looks like a verb"
https://www.merriam-webster.com/dictionary/post
The explanation is that, in HTTP, the semantics of the request are not determined by parsing the identifier, but instead by parsing the method token (GET, POST, PUT, etc).
So the machines just don't care about the spelling of the identifier (besides purely mechanical concerns, like making sure it satisfies the RFC 3986 production rules).
URI are identifiers of resources. Resources are generalizations of documents. Therefore, human beings are likely to be happier if your identifier looks like the name of a document, rather than the name of an action.
Where it gets tricky: HTTP is an application protocol whose application domain is the transfer of files over a network. The methods in HTTP are about retrieving documents and metadata (GET/HEAD) or are about modifying documents (PATCH/POST/PUT). The notion of a function, or a parameterized query, doesn't really exist in HTTP.
The usual compromise is to make the parameters part of the identifier for a document, then use a GET request to fetch the current representation of that document. On the server, you parse the identifier to obtain the arguments you need to generate the current representation of the document.
So the identifier for this might look something like
/invoicedQuantityForPOItems?purchaseOrder=12345&productIdentifiers=567,890
An application/x-www-form-urlencoded representation of key value pairs embedded in the query part of the URI is a common spelling convention on the web, primarily because that's how HTML forms work with GET actions. Other identifier conventions can certainly work, though you'll probably be happier in the long term if you stick to a convention that is easily described by a URI template.
I'm using the Google Places API endpoint "findplacefromtext" and tried a search similar to the example.
https://maps.googleapis.com/maps/api/place/findplacefromtext/json?input=mongolian%20grill&inputtype=textquery&fields=photos,formatted_address,name,opening_hours,rating&locationbias=circle:2000#47.6918452,-122.2226413&key=YOUR_API_KEY
However, when you use this it only ever returns one result. There is a cafe near me that's called "Cream" but when you pass that as the "input" parameter it returns shops that have a category of "Ice Cream". I thought it should only search the name of the business.... If I can't find the place by name does it search the category type as a fall back? When I execute the same search in Google Maps it returns the same data but I get multiple results and I can see the place I am trying to retrieve 3rd on the search result list.
Is it possible to make it return more than one result? The documentation doesn't mention anything about this.
I believe what you need is the Text Search request. The Find Place request is meant for exact addresses.
The Google Places API Text Search Service is a web service that
returns information about a set of places based on a string — for
example "pizza in New York" or "shoe stores near Ottawa" or "123 Main
Street". The service responds with a list of places matching the text
string and any location bias that has been set.
The service is especially useful for making ambiguous address queries
in an automated system, and non-address components of the string may
match businesses as well as addresses. Examples of ambiguous address
queries are incomplete addresses, poorly formatted addresses, or a
request that includes non-address components such as business names.
Taken from https://developers.google.com/maps/documentation/places/web-service/search#TextSearchRequests
FHIR stu3
tried this:
http://fhirtest.uhn.ca/baseDstu3/PlanDefinition/20630?_revinclude=ActivityDefinition
based on the example from :
http://build.fhir.org/search.html#include
but it returned 400 Bad Request
thanks
There are 4 issues with your syntax:
_revinclude is a parameter for the search operation. Searches use the "type" endpoint (i.e. [base]/[resource]). Your format is for a read ([base]/[resource]/[id]). Reads only return a single resource, not a bundle and they don't take most parameters (you can do _format, but that's about it)
_revinclude needs to identify both the resource and the search parameter. E.g. ActivityDefinition:plandefinition, not just ActivityDefinition
The reference in the resources isn't from ActivityDefinition to PlanDefinition, but from PlanDefinition to ActivityDefinition. So you don't actually need a reverse-include. A simple _include is what you need given that your focus is already PlanDefinition
There's no standard search parameter on PlanDefinition to search based on ActivityDefinitions - and both _include and _revinclude are based on search parameters (because that's what servers index).
Because of the 4th issue, you're not going to be able to execute this test against any of the public test servers - unless you make special arrangements, they only support core search criteria. However, on your own system, you're free to define your own search criteria. If you were to do that, you ought to be able to make the query work using the following url:
[base]/PlanDefinition?_id=20630&_include=activitydefinition
(Assuming that you've named your custom search criteria having a path of PlanDefinition.activity.activityDefinition as having a name of "activitydefinition")
When expressing data filters, via GraphQL, should we be creating explicitly-named fields for that filter or should we be adding a parameter to a more generic list-type field that would apply the filter?
For example, if I've got a field called teams but I want to provide the ability to filter the data, provided by teams, down to only the teams who are active (versus inactive), should I expose that filter via GraphQL as a param on the teams field, or should I create a new field called activeTeams?
I'm thinking the clearly, explicitly named fields might scale better and be less confusing in the long run because there won't be questions about how params works when paired with each other, etc.
I wanted to get feedback on how maybe Facebook approaches this, or how others are doing so.
You should add the filter as a param on the teams field as this is the more scalable approach. Introducing a new filter means only a single parameter needs adding. Whereas the multiple-fields approach requires an exponential number of fields for each possible combination.
Don't forget that you can also alias fields on the client if you wish to fetch multiple queries of teams within the same component:
query on Viewer {
activeTeams: teams(active: true) { ... }
inactiveTeams: teams(active: false) { ... }
}