I am trying to perform a filter on a json:api endpoint.
?filter[name]=test name works fine if the name in db is exactly test name. But I want the server to return me values if name is Test name,tEst name or any other combination possible. How can I do this?
Thank you.
The JSON:API specification does not define the filter strategy:
JSON:API is agnostic about the strategies supported by a server. The filter query parameter can be used as the basis for any number of filtering strategies.
https://jsonapi.org/format/#fetching-filtering
It contains a recommendation for filtering strategy that matches your URL design:
It’s recommended that servers that wish to support filtering of a resource collection based upon associations do so by allowing query parameters that combine filter with the association name.
For example, the following is a request for all comments associated with a particular post:
GET /comments?filter[post]=1 HTTP/1.1
https://jsonapi.org/recommendations/#filtering
But even that recommendation does not cover what comparison operator should be used. It also doesn't cover if that should be case sensitive or not. It depends on the filtering strategy picked by the concrete implementation.
Please note that also a strategy encoding the comparison operator in the URL would be valid. E.g. you may encode the comparison operator in the query parameter like this:
GET /companies?filter[name][equalsCaseInsensitive]=test%20name
GET /companies?filter[name][equalsCaseSensitive]=test%20name
GET /companies?filter[sales][greaterThan]=100000
Related
JSON-API provides a way to fetch a collection of resources, or a single resource.
You can get a single resource and specify the inclusion of a relationship like so:
GET /articles/1?includes=author
Is it possible - according to the specification - to get, say, three specific articles in a single request?
Rather than:
GET /articles/1?includes=author
GET /articles/42?includes=author
GET /articles/67?includes=author
Do e.g. (this is made up for illustrative purposes):
GET /articles/1,42,67?includes=author
Yes it is although the spec is agnostic on the details. It does recommend the query parameter "filter" for that and has some recommendations. You would do this with get of a collection with a filter. Something like:
GET /articles?filter[id]=1,42,67&include=author
All, Forgive me I am a newbie in the DICOM world. I tried to learn the DCMTk tools to talk with PACS server. But didn't found much tutorial or sample in the internet to know enough about it .Currently I just have the offical document to read.
I just tried the findscu.exe to test c-find command .
I remembered C-Find would return what specified in the request message. for example. If I only specifed the condition Patient Name ='abc' then the reponse would return only attribute Patient Name. Nothing else.( If it is not right . Please correct me.)
So I want to know how to return all the attribute of response DICOM.
Thanks.
How to specified multiple attributes in the findscu command.
Just specify multiple --key (-k) options on the command line. Alternatively, you could also use a "query file" as described in the man page.
So I want to know how to return all the attribute of response DICOM.
Then, you have to specify all attributes (keys) you are interested in. That's how C-FIND works.
By the way, if you are querying a PACS (Query/Retrieve SCP), then you also have to specify the Query/Retrieve Level (0008,0052), e.g. "PATIENT".
Currently I just have the offical document to read.
If you think that the examples in the man page of the findscu tool are not sufficient (and you are actually querying a PACS), this HOWTO might be useful too.
It is totally legal to send a request with Patient Name information only and the PACS will return all matching datasets.
Each dataset should at least contain all mandatory fields like Date of Birth, Patient ID, and so on, depending on the Query Level.
What information is returned by the PACS system on each Query Level should be specified in the DICOM Conformance Statement of the vendor. I would recommend to take a look at this to know, how to set up a valid query to get the information you need and/or if the information is provided by the PACS system.
It is best to include the Unique key and Required Key Attributes in the request attribute list. Also, include the optional attributes (if supported by SCP) when you wish server to return values for them. Please refer to DICOM Standard PS 3.4 section C.2 and C.3 detail information on Query/Retrieve service. List of attribute and type (Unique, Required, Optional) is listed section C.6.1.1.2 (Patient Level), C.6.1.1.3 (Study Level) and so on.
When i have a resource, let's say customers/3 which returns the customer object and i want to return this object with different fields, or some other changes (for example let's say i need to have include in customer object also his latest purchase (for the sake of speed i dont want to do 2 different queries)).
As i see it my options are:
customers/3/with-latest-purchase
customers/3?display=with-latest-purchase
In the first option there is distinct URI for the new representation, but is this REALLY needed? Also how do i tell the client that this URI exist?
In the second option there is GET parameter telling the server what kind of representation to return. The URI parameters can be explained through OPTIONS method and it is easier to tell client where to look for the data as all the representations are all in one place.
So my question is which of these is better (more RESTful) and/or is there some better way to do this that i do not know about?
I think what is best is to define atomic, indivisible service objects, e.g. customer and customer-latest-purchase, nice, clean, simple. Then if the client wants a customer with his latest purchases, they invoke both service calls, instead of jamming it all in one with funky parameters.
Different representations of an object is OK in Java through interfaces but I think it is a bad idea for REST because it compromises its simplicity.
There is a misconception that making query parameters look like file paths is more RESTful. The query portion of the address is included when determining a distinct URI so the second option is fine.
Is there much of a performance hit in including the latest purchase data in all customer GET requests? If not, the simplest thing would be to do that so there would neither be weird URL params or double requests. If getting the latest order is a significant hardship (which it probably shouldn't be) there is nothing wrong with adding a flag in the query string to include it.
In a current project the UI posts an ordered list of ids of several files under one key to tell the server in which order the files need to be processed:
file[]=18&file[]=20&...
So far the order is preserved when handing this over from client to server, however I could find no specification whether the HTTP protocol keeps the parameters in the specified order. So the question is, is it safe to depend on the given order, or should I implement a workaround to assign each file id a specific order? E.g.
file_18=0&file_20=1&...
Edit:
jQuery Ui has a serialize method, that will pass the parameters just in the initial way that I described above:
foo_1, foo_5, foo_2 will serialize to foo[]=1&foo[]=5&foo[]=2
This is for a sortable list, so I assume they know what they are doing.
Depends on the server. In general, the order is guaranteed by the TCP protocol. If you can read in this order, your HTTP parser stores the parameters in the direct sequence - do not worry. Nobody will be changing these parameters in some places.
HTTP doesn't specify the format of GET and POST data. So they just get passed as blobs of data.
It is up to your form data parser to maintain the order (I'm not aware of any that don't (for identically named fields).
I have come across this issue a few times now, and each time I make a fruitless search to come up with a satisfying answer.
We have a collection resource which returns a representation of the member URIs, as well as a Link header field with the same URIs (and a custom relation type). Often we find that we need specific data from each member in the collection.
At one extreme, we can have the collection return nothing but the member URIs; the client must then query each URI in turn to determine the required data from each member.
At the other extreme, we return all of the details we might want on the collection. Neither of these is perfect; the first can result in a large number of API calls, and the second may return a lot of potentially unneeded information.
Of the two extremes I favour the second in our case, since we rarely use this for more than one sutiation. However, for a more general approach, I wondered if anyone had a nice way of dynamically specifying which details should be included for each member of the collection? I guess a query string parameter would be most appropriate, but I don't want to break the self-descriptiveness of the resource.
I prefer your first option..
At one extreme, we can have the
collection return nothing but the
member URIs; the client must then
query each URI in turn to determine
the required data from each member.
If you are wanting to reduce the number of HTTP calls over the wire, for example calling a service from a handset app (iOS/Android). You can include an additional header to include the child resources:
X-Aggregate-Resources-Depth: 2
Your server side code will have to aggregate the resources to the desired depth.
Sounds like you're trying to reinvent PROPFIND (RFC 4918, Section 9.1).
I regularly contain a subset of elements in each item within a collection resource. How you define the different subsets is really up to you. Whether you do,
/mycollectionwithjustlinks
/mycollectionwithsubsetA
/mycollectionwithsubsetB
or you use query strings
/mycollection?itemfields=foo,bar,baz
either way they are all different resources. I'm not sure why you believe this is affecting the self-descriptive constraint.