When we design Rest apis, it is said that use Path Variable when you need to identify a resource and Request Parameters when you need to do operations like sorting, filtering, searching, pagination. Let us take a scenario of Employee:
Employee has three fields like name, companyName, socialSecurityNo.
Now i want an Employee with a socialSecurityNo = ABC.
It seems fine to have endpoint with path variable like /employees/{socialSecurtityNo}, since we are identifying a resource.
Also it seems intuitive that we are filtering on the basis of socialSecurityNo and have an endpoint like /employees?socialSecurityNo=ABC
What will be the right way as i am confused and think that both apply.
It's a good question.
/employees?socialSecurityNo=ABC
is filtering all employees on socialSecurityNo. If socialSecurityNo is unique to an employee, there's no point in this endpoint existing and a client should use /employees/{socialSecurtityNo}.
There's nothing wrong with filtering on a unique field value (socialSecurtityNo) and if a client finds it easier to use this version (for whatever technical reason) then that's fine. There is no 'right' way. The ultimate reason APIs exist is to allow valuable work to be done by a client. Work with the client to allow that to happen but keep best practice in mind and know when the solution isn't the best but is the most practical in the situation.
I would expect to see:
/employees?surname=Smith
as this is filtering on a non unique field value and should return a collection of Employee objects.
The 'right' thing to do is keep the results consistent. If you have both ways of finding an employee, make sure the returned result is the same in each case.
Related
I'm new to the FHIR World, I have a FHIR client, HAPI FHIR that I can use to fetch data through a restful API. I apology if I missunderstand something during my FHIR documentation journey.
I've look around the documentation and tried some requests to fetch basic data, like a list of Patient, an Observation by id etc..
In my case, I need to get a list of Patient that have the same name as its resource generalPractioner (it's unlikely to happen, it's just an example).
In regular SQL it would look like something like this :
SELECT * FROM Patient
INNER JOIN Practitioner ON Practitioner.id = Patient.practitioner_id
WHERE Patient.name = Practitioner.name
Since FHIR doesn't work that way and isn't relational database, I need to come up with a way to do the equivalent of SQL's WHERE and SQL's JOIN but through the restful API of the client.
My questions are : Is it possible to do these kind of thing directly on a FHIR Client through the API ? If yes, do I need to make new modules inside HAPI FHIR (JPA or plain server ?) (using Java) so it can understand what I really want ?(a new parser with a new route on each resource for example).
Note that the example with the SQL query is pretty simple, my project is to be able to do really nested joins and wheres, as well as the SQL's AND and OR. It doesn't have to use graphQL, this is just what matches the most with my idea while I was reading the documentation.
I'm afraid that regular _include, _filter and _search parameters aren't enough for what I need.
I found that the fhirpath thing could be use but I didn't find how to use it through the API (except with the $graphql operation).
Seems like ChatGPT want me to use the operation $fhirql which is no longer supported in the recent versions of HAPI FHIR, this seemed to be wnat I want.
Thanks !
I do not know what $fhirql is - and I think I know everything there is to know about FHIR. And Google comes up blank, so that might be ChatGPT just fantasising again. Maybe it invented that based on https://github.com/FirelyTeam/FhirQuery, which is clearly the kind of thing you're thinking about.
Or maybe Pathling is closer to what you want: https://pathling.csiro.au.
$graphql only lets you filter your data, it doesn't allow de novo new joins. _filter is the nearest to what you want, for the few servers that support it, but even then, no joins the way you want.
So it looks like you'll have to fetch the data from your API by a client, and then do something locally, which is how those tools work. Unless the server does something specific for you
I'm using Google Data Studio to visualize results from various queries (from different tables within the same BigQuery-database).
For this reason, I created and use multiple data-sources-connectors. Each one of them has a SQL query included and makes use of an defined input parameter (which can be changed by report editors) - called "userid". It is the same id for all queries and resulting charts.
However, when I click "Manage URL parameters", I'm not allowed to use the same URL parameter for more than one data source (instead they are called ds0, ds1, ds2 etc - although they all end up being used as "userid").
If I add a data source under File - Report Settings, a new field "userid" appears, which I can alter - this will update ALL charts in the report with the very same userid (as expected). This works, but I do want to make use of an url which delivers an report with all updated queries depending on ONE userid.
Therefore, I guess I'm overseeing something - it should be possible to just use one query parameter to update the same "userid" for all queries in all data connectors? Or have I overlooked the possibility to fire multiple queries within one data source connector? Or is it expected to create a looong url full of redundant query parameters in this case?
I'm curious for your input!
Best regards :)
There does not seem to be any good solution for this.
For now the best workaround seems to be to just repeat the parameter multiple times -- it's ugly but it works. For example, use the URL parameter mapping screen to call the parameter u1, u2, etc., and then just pass all of them:
?params={"u1":"foo","u2":"foo"}
(URL encoded of course)
The ugliness is mostly for us developers: it violates our sense of DRY and clean code, and makes the URL much longer than it needs to be. However, most people don't care or know about the URL parameters so its irrelevant to them.
The bigger downside is that when the URL is distributed to clients (bookmarks, mobile apps), every time new data sources are added that require the same URL parameters, a new URL has to be distributed to clients for no good reason. A workaround for this is to build the URL dynamically via a simple redirector function.
This issue https://issuetracker.google.com/issues/180705297 is a feature request to implement this capability.
If you group the elements that you want to control with the same parameter (select and then shift G) then it will give you options to select the data source and the params box to apply to the group.
Is it possible with a FHIR search procedure to search for TWO resource types and sort them according to the date? I'd like a list of Observation and QuestionnareResponses, in a single response, returning the newest 10 regardless of resource type.
Searching for one would be:
http://apps.ehelselab.com/baseDstu2/Observation?_sort:desc=date
Any query using the standard "search" capability is always against exactly one resource type. You can include referencing and referenced resources, but filtering and sorting are always done against the "base" resource for the search. To do what you're interested in doing, you have a few options:
define a custom query using the OperationDefinition mechanism (only works if you've got a direct relationship between client and server systems so you can ensure all participants support the operation
Use a "Batch" to execute queries against both, then interpolate the results as you page through both result sets
You can do a query just on the "base", however there isn't presently a way to constrain the types of resources returned - you'd need a custom search criteria
You might be able to use the _filter mechanism - I haven't dived into it very deeply. But I suspect that it also uses the "single target resource type" approach.
The best bet is probably #3. If you submit a request to add a search criteria to "Resource" allowing constraining the resource type, that would probably let you do what you wanted.
In my page I ve to pass multiple values to controller.
My URL looks something like :
http://blah/Search/Page/?type=new&keywords=blahblah&sortType=Date
Is Passing multiple values as query string good practice in MVC ? or We can have slash separated URL, by using introducing custom routing?
NB: Lets consider all the values in my query string, are not secure / sensitive data.
I wouldn't consider it a bad practice, as long as it's not senstive data. It just depends if you want to write a custom route in your global.asax to handle it or not. The custom routes provide a cleaner url forsure. Also, for more savy users if they understand the concept on your site, it's more intuitive.
So consider this:
http://baseballcards/topps/1980 // search for baseball cards made by topps in the 1980s
http://recipes/deserts/pies // search for a desert recipe that are pies
http://code/csharpe/linq // search for csharp code that has linq examples
In these examples we can almost read the url like a sentence, making it more intuitive, giving a user the ability to plug and play. It clearly denotes the query almost like a breadcrumb, indicating exactly what the context will be. I personally like this. But either way is a good approach.
To extend with more parameters:
routes.MapRoute(
"SearchRecipes",
"Search/Recipes/{category}/{type}",
new { controller = "Search", action = "Recipes", category = "all" , type = ""}
);
Some examples:
Search/Recipes/Deserts/Pie
Search/Recipes/Dinner/Beef
Search/Recipes/Lunch/Salads
Select later (query string in route values) in case,
If you are concerned about header length.( By default get parameters are part of headers, and web server accept 1024 byte header length by default in IIS7).
Hide logical implementation of your code.
Url looks good and easier to remember.
Otherwise Both the approaches work equally.
I think passing search parameters in the query string is the way you should go, especially if all your parameters are optional. It also enables you to use normal method="get" forms without hassle.
I don't think "security/personal data" has anything to do with this since the query string is a part of the URL just like the path is.
IMO I think this is absolutely fine. I think it is actually preferable to use querystrings in MVC when the path represents the function and the querystring parameters represent the filters, e.g. as in a search.
However, I wouldn't use querystring parameters for data that represent information about the content retrieved. So I would include the year and month of an article in the path but not the page number if returning more than one page of articles for the year and month.
A question based on a comment made here:
storing user detail ... session vs cache !
Summary: I mentioned a technique I've used where I populate a model and use hidden fields to keep and pass back that information; Viewstate on the cheap. Simon Halsey said that the information should be encrypted or hashed so it is not tampered with. I'm thinking the added complexity of hashing it is just a form of YAGNI.
I can see that for sensitive information, definitely, but is this a good rule of thumb in general? What am I missing?
I actually have an attribute to do this (something similar) and speak about this exact thing in a security presentation. Yes - you should hash a copy of the value... encrypting it is up to you. if you encrypt it you get no model binding but is more open to attack, although a hash check helps. I'll post the code shortly for it and update this post. Who would ever think Viewstate helped with security : )
but to answer your question - you can encrypt it, but you need a way to at least validate it on the server side, so I hash a value and hash the posted value and then compare hashes in the attribute. encrypting can help - but then you need to implement either your own model binder or manually handle those values
The rule of thumb would be generally for any values that could be maliciously overwritten to attack your data - then you want some protection/validation on those fields. you could compare server side against what you know is a valid option for them (a form of whitelisting) but then you have the same form of rules duplicated on loading the data and on saving the data and that gets a bit messy at times, unless its as simple as limiting a user's get/update to a single userId.
What I mean is.. if you are updating say a user's record. Generally the main thing that matters for security is that the userId is not changed by the user to update a record that isn't theirs. The logic on get/save is easy "where o.UserId == userId"
However in complex role based security the logic becomes trickier and is not as clean to limit record updates like this. In those cases you can really take advantage of encrypted/hashed fields. I always hash the specific fields uses for update. Sure - they can be forged with other valid hashed fields from a previous request, but the scope of potential damage is significantly more limited this way.