What do you think about making the "time" property optional in request body to provide more flexibility. This property could be added automatically with current date and time when not present in the request.
It could be useful for SigFox compatibility for example because even if it's possible to add a {time} pattern in message body forwarded by SigFox system, there is no way to modify the format of the datetime generated. Currently the {time} pattern generate a Timestamp and Cumulocity expect an ISO 8601 formatted date time.
Currently I got a "422 - Unprocessable Entity" even if the request is TRANSIENT when I give a Timestamp or no time property when calling Cumulocity. I had the idea to make a TRANSIENT request to store an Event by writing a CEL statement to generate the missing "time" property but it's not possible because the error appears before reaching the event process.
Do you know an other way to do operate?
You can take a look at SmartREST (http://cumulocity.com/guides/reference/smartrest/).
It allows you to create templates for you requests on the server side. Afterwards you just send the values to replace in the template as csv (+ the template id).
It also allows you to let the time value be automatically set by the server.
Related
I have just started learning oracle apex.
I imported an external API into oracle apex(https://localhost/report/?dateFrom=2022-09-30&dateTo=2022-10-01) . This API has two parameters dateFrom and dateTo. I want to dynamically set the datefrom parameter to 5 days ago and dateTo to today in default value. How can I do this?
One option is to define the parameter value for the component, which is using the REST data source. If that is, for instance, a report, you can configure within the Parameters Node in Page Designer. In the tree on the left hand side, click the node for your parameter, and then (in the Attributes pane on the right, choose Expression or Function Body, and enter the expression to compu For a REST Synchronization (download data to local table), you would configure the same as a Synchronization Step.
These options will configure the dynamic value at the component level (the component which uses the REST Data Source).
However, your question reads like you're after a default to be applied to all components using that REST Data Source. The Expression or Function Body options are not available at the REST Source level. I'd see two approaches:
Define an application item (APP_REST_DATEFROM), and a Application Computation to set the value for this item. In the REST Source, then simply use &APP_REST_DATEFROM. as the value for your parameter. At the component level, it's important to switch the parameter value to REST Source Default.
Another option allows you to completely take these parameters out of the REST Source configuration, but implies some PL/SQL coding effort: You could author a REST Source Plug-In, where the Plug-In code implements custom handling for all aspects of the HTTP requests being made for the REST Data Source. That typically includes pagination, but can include all parameter handling (HTTP Header, URL Parameters, etc). An example for such a Plug-In is here: https://github.com/oracle/apex/tree/22.1/plugins/rest-source/fixed-page-size
I hope this helps.
I am currently working on a REST API for a project. In the process I should search for events. I would like to make an endpoint for searching events in a period. That is, specify two parameters with from - to.
For the search you normally take a GET operation. My question is now it makes sense to specify two parameters in the path or should I rather fall back to a POST operation for something like that.
Example for the path /Events{From}{To}
Is this even feasible with multiple parameters?
If you are not making a change on the resource, you should use GET operation.
More detailed explanation:
If you were writing a plain old RPC API call, they could technically interchangeable as long as the processing server side were no different between both calls. However, in order for the call to be RESTful, calling the endpoint via the GET method should have a distinct functionality (which is to get resource(s)) from the POST method (which is to create new resources).
GET request with multiple parameters: /events?param1=value1¶m2=value2
GET request with an array as parameter: /events?param=value1,value2,value3
I am trying build an api which conforms to the json:api spec.
My api has three resources /task, /item and /result. A task has the fields name, description and state. A item has the fields itemName. A count is kept server-site for the item and the count is returned when a user retrieves the item with a GET request. The count is incremented server-side when the item is updated. There is a one-to-many relationship between task and item. In a sense an item is appended to a task. When the tasks state changes a script runs server-side to do some processing on the associated items. Once the script finishes the output is available in the result resource.
Per the spec, I am using the POST verb to create a task and the PATCH to update a task. I just want one endpoint which handles both the create /update (appending) of an item. But, I'm not sure which verb to use? Can I use PATCH to update the item but also create an item if it doesn't exist?
I also thought that perhaps I should be using the PUT verb. But, my understanding here is that this verb is used to simply replace a resource rather than update it. I don't think this is right for my user-case as an items count is incremented when updated, so replacing it is not what I want todo. But, the count is handled server-side so a user doesn't have the option of "replacing" the count anyway.
my understanding here is that this verb is used to simply replace a resource rather than update it.
This is a common understanding - wrong, but common.
The IANA registry documents the authoritative reference for the semantics of http methods. Most of the common ones are defined by RFC 7231; PATCH is defined by RFC 5789.
PUT is an appropriate choice when the message body is a complete representation of what you want the resource to be. It may be easier to think about "saving a file"; PUT describes what the client expects the document to look like when it has been saved.
It's appropriate to use PUT for either updating a document or creating one, provided that the client knows the identifier for the document (just in the same way that we can use save to create a file, or replace a file, but we need to know the file name).
If you read the text of the specification, you'll see that - while the semantics of the request are to save the new representation "as-is", the server isn't required to do that -- the server, after all, is in control of its own documents -- so there is room to cover read only fields, or fields that should be updated by the server only. You need to have a little bit of care with the response headers to avoid implying that you saved the representation as is, but other than that you should be fine.
I am developing rest api update method for user profile resource user/profile. I am disappointed what http method should i use. Update contains some required attributes so it more PUT request, where client need to fill all attributes. But how it can extend attributes in future. If i will decide to add new attribute then it will automatically clear because client is not implement it yet.
But what if this new attribute has default value or is set by another route?
Can i use PUT with not stricting number of attributes and use old data if new isn't come in request. Or how it can be done normally?
HTTP is an application whose application domain is the transfer of documents over a network -- Webber, 2011.
PUT is the appropriate method to use when "saving" a new version of a document onto a web server.
how it can extend attributes in future.
You design your schemas to be forward and backward compatible; in practice, what this means is that you can add new optional elements with reasonable default values. When you need to add a new required element, you change the name of the schema.
You'll find prior art in this topic by searching XML literature for must ignore.
You understand correctly: PUT is for complete replacement, so values that you don't include would be lost.
Instead, use the PATCH method, which is for making partial updates. You can update only the properties you include values for.
I have been trying to figure this out as I am working on a deliverable for which I need to provide metadata for emails. As the title suggests when I am recording this metadata often the MailItem.Senton property will be greater than the MailItem.ReceivedTime property. How is this possible?
This is due to the fact that these values come from different places - the Date MIME header is created by the sender, while the received time is based on the receiving machine time.