I am trying to update one resource but the request body is bundle. I have tried to update by sending following combinations of URL:
resource_type/resource_identifier and bundle/bundle_identifier and bundle/resource_type/resource_identifier.
but none is working. I am getting error Cannot update bundle.
Server is hapi server.
Is it possible to update the bundle or i will have to extract the particular resource from bundle and then update it.
Updating a Bundle wouldn't impact data on the AllergyIntolerance, Patient or Encounter endpoints, it would just change what would show up if you queried the Bundle from the Bundle endpoint. If you want to submit a Bundle that isn't stored as a Bundle but instead causes data at the other endpoints to be changed, then you need to POST a Bundle of type 'transaction' to the root endpoint (i.e. http://someServer.org/fhir rather than http://someServer.org/fhir/Bundle). The transaction Bundle would have the 'request' element present and would define what RESTful operation to perform on each resource (e.g. create/POST, update/PUT, etc.) You can see an example of a transaction request here: https://build.fhir.org/bundle-transaction.html. (Click on the syntax you prefer.)
If you want to store a Bundle and update individual resources, then you'll have to POST twice - once to the root endpoint and once to the Bundle endpoint.
Related
I am using laravel and vuejs for a project.when a page is rendered, api requests are sent to laravel and I get back as a response some data, how can I save these response data inorder to avoid sending requests every time I refresh the page?
I want to avoid sending requests everytime I refresh the page so I only send the request one time and then save the response somehow somewhere and by refreshing no more api requests are sent.
local storage is not very safe, and vuex store gets empty by refreshing the page is there some other way?
Though your answer might be duplicate you can use the vuex-persitedstate plugin. This plugin offers the options property which provides a white list of variable paths which you wanted to be persistent.
See the example below, you could try adding ‘setCounts’ to the paths option, which will be persistent.
Example:
const store = new Vuex.Store({
// ...
plugins: [createPersistedState({
paths: ['setCount']
})
option paths is an array of any paths to partially persist the state. If no paths are given, the complete state is persisted. If an empty array is given, no state is persisted. Paths must be specified using dot notation. there are other options, you can check vuex-persistedstate
You can install a vuex plugin called 'vuex-persistedstate' which can be install via npm then in your vuex index.js file you need to import createPersistedState from 'vuex-persistedstate';
and below 'export default' add plugins: [createPersistedState()],
You can also try Service Workers. For that, you may need to check progressive web application implementation. But if your application has a lot of APIs which needs to be cached, with timely update, you can go with service workers.
I am trying to use the rest API to dynamically update and control my Apache NiFi Flow. I am using Postman to explore the REST API but am having trouble deleting properties/descriptors.
My current process is to call a GET to this address - http://localhost:8080/nifi-api/processors/{ID}
I then modify the response as desired and do a PUT with the modified response as the body. If I add a descriptor or change the content of a descriptor it works ok. But if I try to delete a descriptor by removing it from the properties and descriptors area then nothing happens.
I still get a 200 OK response, but it is the same as the original.
I am using NiFi 1.1.2 on Windows.
The PropertyDescriptors are specified by the Processor in question. These are read-only values and describe the properties the Processor currently supports. In you want to remove a property, and it is optional, you should be able to remove the value for it by setting it's entry to null in properties object in your request.
I am currently using the Marklogic spring boot demo. So far I have been able to add indexes, facets, front-end logic etc just fine.
Right now, I am trying to layer in some semantic logic into a rest endpoint.
I wrote a simple query into the query console, and attempted to add it to the src/main/ext folder so that it would get deployed by the ml-gradle bootrun.
Right now. This file will get deployed to the test-modules database, and is visible once saved (I can see it in explorer under URI /ext/my-endpoint. I also tried adding a folder named rest-api but that just adds it to /ext/rest-api/my-endpoint
At the top of the endpoint I have it declared as
`module namespace ext = "http://marklogic.com/rest-api/resource/my-endpoint";
However when I navigate to the URL it should be living at http://localhost:8090/LATEST/resources/my-endpoint?
It tells me it does not exist.
So I can see it in the modules database, but I can't use it on HTTP. the Query works in the query console (and is rather trivial, and-query of json-property-word-queries)
My question is:
How can I properly update the marklogic-spring-boot framework to properly deploy rest endpoints.
So I figured it out it seems.
Manually creating the file isn't registering the distribution workflow properly.
Instead I create the resource using ml-gradle
gradle mlCreateResource -PresourceName=my_endpoint
This will create a new folder called services, and create the endpoint for me, which can then have code over written.
Still not sure what gradle is doing special, so I can know what the proper way to do this manually would be, but at least it works.
To update the resource i have exposed following reset web api url -
http://server.com/api/v1/{companyid}/resources/{resourceid}
and request body contains the resource to be updated.
I have also exposed a seperate API to update a property of same resource. From business rule perspective this is special property and cannot be updated/retrieved along with normal resource api.
So using following url to expose separate api as below -
http://server.com/api/v1/{companyid}/resources/{resourceid}/property?propertyKey=propertyValue
this does not sound good. Is there better approach?
Answer from the comments for others
PUT api/v1/{companyid}/resources/{resourceid}/{property} with the Body containing the value of the property is one way.
PUT api/v1/{companyid}/resources/{resourceid}/{property}/{propertyvalue} is another way if you want the value entirely in the URL.
Of course, http://server.com/api/v1/{companyid}/resources/{resourceid}/property?propertyKey=propertyValue is also probably fine.
As #David-Brabant mentioned don't version your API's in the URL
According to the specification here, if you create a resource the server should return a 201 created along with a Location header which contains the new Logical Id and Version Id of the created resource.
I am uploading a patient resource to http://fhir.healthintersections.com.au/open/Patient and using the Chrome debug tools I can see that a 'Content-Location' response header is returned that contains the Logical ID but I cannot access this using jqXHR.getResponseHeader('Content-Location') or jqXHR.getAllResponseHeaders().
After much searching, the problem seems to be that unless the Access-Control-Expose-Headers
header is added to server, I can't view the header within my application as it is a cross origin request.
Is there another way around this problem so I can find the logical ID after creation of a resource?
FHIR exposes it's metadata (id, version specific id, last updated) only in the headers, so you really need to get to that Location header to get a newly created resource's id. There might be a work-around, which is using the "search" operation to retrieve a feed with only this newly created resource (assuming it has identifying business keys like patient id). The resource's atom entry will have an with the id.
That said, that's truly a hack. This is not a FHIR related issue however (see for example How to get responseheader location by jquery).
To fix this problem, I'll update my FHIR server (at spark.furore.com/fhir) to include these Access-Control-Expose headers. It should be updated in the next few hours, so you can try whether that works for you.