Hi I am following this doc https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md#strategic-merge-patch for strategic-merge-patch to partially update the JSON objects using PATCH REST API. The document says that it can add or delete the object, but I have tried, whenever I add new object to existing JSON it just replaces that instead of adding new. I am trying this to modify pod definition in OpenShift 3.2. can anyone please help me how it works, probably with example. I need to use delete operation also , where I can delete the value by name.
As documented it depends on annotations of the types. AFAIS the strategic merge only works if patchStrategy and patchMergeKey are given. For example, this is the case in pod.spec.containers and pod.spec.volumes.
For an example you need to provide more information about the type you want to merge.
Related
I am trying to dynamically create environments with a set of specific predefined tasks and steps.
Anyone ever got this working well enough to post some sample code, or a guide?
I can't add an environment, or tasks to an existing one. I keep getting an error BadRequest, but I don't know what am I doing wrong in the JSON payload.
I can get the existing definition, I can do simple things like update the name of the release definition, comments and description when I update, but once I touch the environments it all breaks.
I am using the online URIs -
https://vsrm.dev.azure.com/{acct}/{proj}/_apis/release/definitions?api-version=5.1
Is there any way to get more information on what's wrong with my payload, what's bare minimum, or required?
If you mean create/update environment for the specific release definition, then you can try the following steps:
Get that release definition response and convert the response to JSON body:
GET https://vsrm.dev.azure.com/{organization}/{Project}/_apis/release/definitions/{definition ID}?api-version=5.1
Add (insert) a new environment (or update the existing one) to that JSON body. You can copy from the existing environment block, then change the parameters accordingly. For example: Add a new environment with "id":0, set a new name, the ranks of release pipeline stages need to be consecutive natural numbers, for example, the rank in previous stage is "2", then it should be "3" here. Keep others same as previous one
Update the release definition by calling the REST API with the updated JSON body:
PUT https://vsrm.dev.azure.com/{organization}/{Project}/_apis/release/definitions?api-version=5.1
You can reference the below screenshot for details:
I'm a little confused about put method with optional paramter.
suppose the mode is
Pet {
name
catagory
tag (optional)
}
when I want to create a Pet, I can use post method, the tag can be omitted.
when I want to update a Pet, the problem comes to me. According to the http spec, PUT method will update the entity by replaces the whole resource, which means I need to pass tag parameter. If I didn't pass tag, the default value will be empty, but it will cause the existing tag be override to empty.
For patch method, it will only update partial parameter no matter if it is optional. It's clear to understand.
I don't know if I misunderstand something, currently, in PUT method, I need to figure out what parameter is passed, and then update correspond field. But this seems the same with PATCH method.
An important thing to understand is that the HTTP specification describes the semantics (what do the different requests mean), but does not describe the implementation (how do you do it). That's deliberate - the specification basically says that your server should pretend to be a key/value store, but it doesn't restrict how you implement that.
PUT is roughly analogous to saving a file: "here is an array of bytes, save it using this key". In cases where your storage is a file system, then you just write the array of bytes to disk. If your storage is an in memory cache, then you just update your cached copy.
If your storage is some RDBMS database? Then you have some work to do, identifying which rows in your database need to be changed, and what commands need to be sent to the database to make that happen.
The point is that the client doesn't care -- as a server, you can change your underlying storage from RDBMS to document stores to files systems to whatever, and that's not any of the client's business.
in PUT method, I need to figure out what parameter is passed, and then update correspond field. But this seems the same with PATCH method.
Yes. In both cases, you need to figure out how to edit your resource in place.
PUT may feel a little bit easier, in that it is semantically equivalent to "delete the old version, then create a new version". You don't have to worry about merging the provided data to the state you already have stored.
I have a webserver with some configuration properties and I want to be able to change them using a REST API.
Example
{
"maxUsers" : 10,
"refreshPeriodInMin" : 5
}
I would like to represent this with a "configuration" object. According to REST principle I believe the best way to do it is :
GET/PUT/POST/DELETE /configurations/{id}
But in my case I have only one configuration object and I do not like the idea of have to query
GET /configurations
just for one object.
Because there is only one object the easiest solution I found is to use id=default
Would give something like
GET /configurations/default
Is there a better way to represent a "unique" resource ? As mentionned by djmorton in the comments would /configuration be correct in a REST world ?
Another solution I though about would be to have one object per property. This would give
GET /properties/maxUsers
Problem with that solution is that you need to know the name of property to be able to query it. PLus you will make several queries if you have multiple changes to make.
Keep the resource singular if it truly represents a singular thing. If you will only have one, there is no reason not to simply PUT to that resource when you want to create or update it, and GET from that resource when you want to retrieve it.
If it can not be deleted, return a 405 METHOD NOT ALLOWED on DELETE requests. If it can be deleted, a DELETE request to that resource is acceptable, after which GET requests can return a 404 NOT FOUND.
In many ways, adding an id element to the path like /configuration/default would probably confuse users because they might expect that they would be able to POST new configurations to /configuration in addition to the default one.
The key is to do something that is sensible and intuitive to consumers of the API.
I have a rule where in RHS I insertLogical another Fact. In Drools 6.2 we can deploy the rules in a container and then fire the rules on that container. When I run the POST request for fireAllRules(batch-execution), I can just get back the facts which I inserted. There seems to be no way to access the insertLogical Fact. Even the getObjects expects fact-handle and since I had not insert the fact there is no way to get it. Is there an option to get fact inserted in RHS?
Other option I thought of trying out was to add another REST url which I can expose from with-in container. This url can fire rule locally from within container and pass me back custom objects. Is this possible?
A simple solution for your situation could be to define a query in your DRL to return the logically-inserted fact.
Using a BatchCommand you can then execute that query and get its result.
Hope it helps,
I'm working on a REST-like API.
This API have a this for changing a existing resource by ID:
/api/v1/admin/member/:ID
I any normal circumstances this would of course be a PUT when changing a resource.
But because of a compromise leading to simpler code, this route actually first delete the resource completely (and all references to it) and then create a new one based on the input given by a form.
In all means this will look and give the same end result as a resource change.
Question: Should this route be a PUT or a POST
The expected behavior is idempotent so I would say use PUT, and I would make sure the update occurs in a transaction so an error between deleting and inserting would not leave the resource deleted.