Fhir object model is a resource driven model which is fine. As a client , let's say I want to get patient information. I called - 'patient/1'. Now , to get related resources like Organization , Care provider - do I have to make 2 other calls?
To get all patient related information with a single call , what do I need to do?
To get everything related to patient, look at the $everything operation (http://www.hl7.org/fhir/patient-operations.html#everything). You can also bring back related information when querying a single resource by using _include and _revinclude (see http://www.hl7.org/fhir/search.html#revinclude)
Related
We are revamping a big enterprise application which has more business workflows. We are using activiti bpm with spring MVC. Currently we are saving the required variables for workflow inside execution individually. My idea is to create object for each workflow and save the object as variable inside activiti execution instead of individual variables.
For example for the job application workflow I will have JobRequest object which have all the requested details like approvers, interviewers, candidate profiles, current status, etc., I will save this object as variable inside activiti. Whenever I need I will just get the object back and show the needed info on the web page. It will be hassle free than maintaining all those information on separate tables and getting the reference alone from activiti.
Is this good approach?
Still I have some concerns on my approach.
If suppose later we add additional fields to the Class. Then how to
handle the history object variables. (In the above example we are
adding additional field under JobRequest.class).
In our current approach if some values really needs to be verified I
can connect to the activiti database and able to see. Because the
variables are saved individually.
Any valuable suggestion?
I am working on an .net application that needs to present to the user data from 3 different platforms and any actions taken are also saved to the respective databases. What is the best design pattern for data access ,I am thinking Factory would be best but i need some advice as I am kind of new to this approach.
Lets say we have 5 different websites that are independent of each other completely , but similar . Products added to these different sites need to be reviewed in a single application and each product is either approved to rejected by the user . We dont need to combine the data , but the UI is the same , based on what data they are looking at , we just need to save the actions to that particular db.
Yes, and is most common to use.
Look this site: http://www.primaryobjects.com/CMS/Article81.aspx
Contains a simple step to step how to create a database factory in C# for web pages.
I would say an Observer pattern:
(for receiving messages of new products if you are not polling manually)
coupled with a Command pattern:
(for agnostically rejecting/approving a product and sending it off to be processed by its DB)
You could then interface the brokering class with a Factory pattern. Im just curious on how you would get notified of a new product: polling, pushing, sockets, etc since that would open up more options for your solution
As per REST framework, we can access resources using GET method, which is fine, if i know key my resource. For example, for getting transaction, if i pass transaction_id then i can get my resource for that transaction. But when i want to access all transactions between two dates, then how should i write my REST method using GET.
For getting transaciton of transaction_id : GET/transaction/id
For getting transaction between two dates ???
Also if there are other conditions, i need to put like latest 10 transactions, oldest 10 transaction, then how should i write my URL, which is main key in REST.
I tried to look on google but not able to find a way which is completely RESTful and solve my queries, so posting my question here. I have clear understanding of POST and DELETE, but if i want to do same update using PUT for some resource based on condition, then how to do it?
There are collection and item resources in REST.
If you want to get a representation of an item, you usually use an unique identifier:
/books/123
/books/isbn:32t4gf3e45e67 (not a valid isbn)
or with template
`/books/{id}
/books/isbn:{isbn}
If you want to get a representation of a collection, or a reduced collection you use the unique identifier of the collection and add some filters to it:
/books/since:{fromDate}/to:{toDate}/
/books/?since="{fromDate}"&to="{toDate}"
the filters can go into the path or into the queryString part of the url.
In the response you should add links with these URLs (aka HATEOAS), which the REST clients can follow. You should use link relations, for example IANA link relations to describe those links, and linked data, for example schema.org or to describe the data in your representation. There are other vocabs as well, for example GoodRelations, and ofc. you can write your own vocab as well for your application.
I'm a newbie in Freebase Topic API. Currently I am looking for "How to retrieve specific set of data using Freebase Topic API?"
for e.g. if we request for particular information using following URL
https://www.googleapis.com/freebase/v1/topic/en/nicobar_scrubfowl?filter=/common/topic/description
we get ample of information like "id","property","values" array containing "text","lang","value" etc.. And I don't want all the information.
So how to retrieve particular set of information using topicAPI (like only "value" from "values" array OR only "provider" etc..)
thanks
If you want that level of control, you should investigate the MQLRead API.
There's no way to filter out those parts of the Topic API response. Every property value will have at least text, lang, id, creator and timestamp.
Why is this a problem in your application? As long as you're parsing this data with a JSON parser you will be able to access any of the data you want while ignoring the rest. If you're worried about the size of the response you can ask for a GZip response.
I'm well into implementing a REST service (on a Windows CE platform if that matters) and I started out using IBM's general definitions of using POST for creating (INSERTs) and PUT for updating.
Now I've run across Sun's definitions which are exactly the opposite. So my question is, which is the "generally accepted" definition? Or is there even one?
The disadvantage of using PUT to create resources is that the client has to provide the
unique ID that represents the object it is creating. While it usually possible for the client
to generate this unique ID, most application designers prefer that their servers (usually
through their databases) create this ID. In most cases we want
our server to control the generation of resource IDs. So what do we do? We can switch
to using POST instead of PUT.
So:
Put = UPDATE
Post = INSERT
The reason to use POST as INSERT and PUT as UPDATE is that POST is the only nonidempotent and unsafe operation according to HTTP. Idempotent means that no matter how many times you apply the operation, the result is always the same. In SQL INSERT is the only nonidempotent operation so it should be mapped onto POST. UPDATE is idempotent so it can be mapped on PUT. It means that the same PUT/UPDATE operation may be applied more than one time but only first will change state of our system/database.
Thus using PUT for INSERT will broke HTTP semantic viz requirement that PUT operation must be idempotent.
The verbs are:
GET {path}: Retrieve the resource whose identifier is {path}.
PUT {path}: Create or update the resource whose identifier is {path}.
DELETE {path}: Delete the resource whose identifier is {path}.
POST {path}: Invoke an action which is identified by {path}.
When the intention is to create a new resource, we can use PUT if we know what the identifier of the resource should be, and we can use POST if we want the server to determine the identifier of the new resource.
PUT can be used for creation when the server grants the client control over a portion of its URI space. This is equivalent to file creation in a file system: when you save to a file that does not yet exist you create it and if that file exists the result is an update.
However, PUT is lacking the ability of an implicit intent of the client. Consider placing an order: if you PUT to /orders/my-new-order the meaning can only ever be update the resource identified by /orders/my-new-order whereas POST /orders/ can mean 'place a new order' if the POST accepting resource has the appropriate semantics.
IOW, if you want to achieve anything as a side effect of the creation of the new resource you must use POST.
Jan
We use POST= Create, PUT= Update.
Why? There's no good reason. We had to choose one, and that's that choice I made.
Edit. Looking at other answers, I realize that the key creation issue might make the decision.
We POST new entries and return a JSON object with the generated key. It seems like this is a better fit for generally accepted POST semantics.
We PUT to existing entries with a full URI that identifies the object.
Here http://www.w3.org/Protocols/rfc2616/rfc2616.html is the offical guide of how to implement the behaviour of the HTTP methods.
I've been studying the concepts and implementations of REST a lot lately and the general consensus seems to be: PUT is used for creating/updating depending on whether or not the resource already exists. POST is used to append a resource to a collection.
See HTTP/1.1 Method Definitions http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
POST is designed to allow a uniform method to cover the following
functions:
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing
list, or similar group of articles;
- Providing a block of data, such as the result of submitting a
form, to a data-handling process;
- Extending a database through an append operation.
The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already existing
resource, the enclosed entity SHOULD be considered as a modified
version of the one residing on the origin server.
Also see the accepted answer to the question at Understanding REST: Verbs, error codes, and authentication.