During an update of streaming jobs (via REST Api, we use the generic one that allows to update any kind of resource: https://learn.microsoft.com/en-us/rest/api/resources/resources/updatebyid), I get 422 without any additional information. Could anyone help with identifying the problem ?
Well, although there is very little useful information in your question, I eventually reproduce your issue on my side.
The reason has been described clearly by the error message :
PATCH of Inputs, Transformation, Functions, Outputs or Devices is not allowed using the Streaming Job level API. Please use the API for the corresponding resources.
This means you could not include the Inputs, Transformation, Functions, Outputs, Devices in your request body, because they are different resources form the streamingjobs.
Solution:
To fix the issue, just use the API for the corresponding resources as mentioed in the error message.
1.Update Input : PATCH https://managment.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.StreamAnalytics/streamingjobs/{job-name}/inputs/{input-name}?api-version={api-version}
2.Update Function : PATCH https://<endpoint>/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.StreamAnalytics/streamingjobs/{jobName}/function/{functionName}?api-version={api-version}
3.Update Output : PATCH https://managment.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.StreamAnalytics/streamingjobs/{job-name}/outputs/output?api-version={api-version}
4.Update Transformation : PATCH https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.StreamAnalytics/streamingjobs/{job-name}/transformations/{transformation-name}?api-version={api-version}
For more details, you could refer to Stream Analytics REST API.
Sample:
I test to Update Input.
PATCH https://managment.azure.com/subscriptions/xxxxxx/resourceGroups/joywebapp/providers/Microsoft.StreamAnalytics/streamingjobs/joyteststream/inputs/joyinput?api-version=2018-11-01
Request body:
{
"properties":{
"type":"Stream",
"serialization":{
"type":"JSON",
"properties":{
"encoding":"UTF8"
}
}
}
}
Result:
Related
So I'm experiencing some issues in Azure Data Factory.
I have a standard pipeline where I'm trying to implement a webhook for later callbacks, but the body for the webhook post does not seem to be behaving.
(In advance: sorry for the image URLs -> I'm not reputable enough to post images)
So here is what I've typed into the "Body" of the Webhook service: https://imagizer.imageshack.com/img922/3765/ApbiRN.jpg
Then I verify that the template looks correct:
https://imagizer.imageshack.com/img924/5448/vN82Vp.jpg
And finally I debug the pipeline only to find this as output from the webhook: https://imagizer.imageshack.com/img923/3697/AEDzOT.jpg
As you can see it's grabbing a {"Key":"Value"} from somewhere.
Now I've saved the pipeline; I've published the pipeline; I've restarted ADF.. Still.
So the first issue is that I'm not able to send the body that I want.
The second issue is that I'd like to parameterize the body (when this is cleared up):
{
"key1":"#{pipeline().parameters.param1}",
"key2":"#{pipeline().parameters.param2}",
"key3":"#{pipeline().parameters.param3}"
}
I've not been able to solve that last one either, so if any kind souls would be so kind.. much obliged!
Edit: In addition I've not been able to spot the "callBackUri" that the documentation promises: https://learn.microsoft.com/en-us/azure/data-factory/control-flow-webhook-activity
Any insights into that issue as well?
I tried many times and finally succeeded.
In your case, you can use the expression as follow:
#json(concat(concat('{"key1":"',pipeline().parameters.param1,'",'),concat('"key2":"',pipeline().parameters.param2,'",'),concat('"key3":"',pipeline().parameters.param3,'"}')))
The result is as follow:
First, we need to concatenate the query string.
Then we need to use #json() to convert the string type to json type.
We are currently trying to come up with a set of REST API that would fit our resource models.
A simplified example of the resource is:
CompanyInfo: {
totalNumberOfEmployees: Number,
employees: [...employees],
}
Employee: {
name: String,
}
In this case, "CompanyInfo" is like a virtual resource that does not exist in DB. It is a short cut for getting all the data related to the Company resource. The idea was to reduce the amount of logic on FE and create more convenient endpoint instead.
Our current endpoint design is:
GET /api/companyInfos/{companyId}/employees
GET,POST,PUT,DELETE /api/companyInfos/{companyId}/employees/{employeeId}
The reason for the extra {companyId} is because these endpoint does not return "Employees", it instead return a "CompanyInfo" that contains "Employees" embedded in the payload.
This is to avoid the aggregated property "totalNumberOfEmployees" not being updated in case sync when we call POST to create a new "Employee"
So my questions are:
Is this the correct approach to the problem of "too many requests" or "too much logic in FE"?
Is it acceptable for the endpoint to return a completely different resource than what its url describe?
Thanks a lot :)
For your Fist question
Is this the correct approach to the problem of "too many requests" or "too much logic in FE"?
yes Sometimes this is how it is suppose to be done. when data sent is small in each request. to many request does not affect the performance so This is how it is suppose to be done .
And Generally it is recommended to write one monolithic Ajax call in front end which will be capable of making any kind of call , By taking callback as parameter, and method , arguments as parameters .
So it will not be to much of logic if you follow this approach . All you have to write is callback for each of Ajax call . How ever sometimes situation may not allow for this Example:if you are using content-type like 'multipart/mixed'
there you have to write another ajax call code
However nowdays most front end has too much of logic based on how interactive website is . So your primary concern should be about look of web site .
For you second question
Is it acceptable for the endpoint to return a completely different resource than what its url describe?
yes . It is acceptable . but it is recommended that client mention all the MIME types which it expects in Accept header and Only those MIME types should be returned by Api.
I am using Spring Cloud Contract to create stubs for a REST service so I can test with a REST client. I have the stub runner working within a Spring Boot application, and it all works as expected. The problem I am having is that I'd like to see elements of the requests in the responses, to better simulate the eventual behavior of the REST service. For example, in this contract, I'd like what is passed in the "code" field in the request to appear regurgitated in the response:
package contracts
org.springframework.cloud.contract.spec.Contract.make {
request {
method('POST')
url $("/resource")
body ([
code : $(client(regex('[a-zA-Z0-9]{5,32}')))
])
}
response {
status 200
body([
code: ???
])
}
}
Obviously the input "code" can be anything that matches the regular expression, and so the actual value is unknown until runtime. Is there anything i can put in place of "???" to return the code submitted in the request ? I tried accessing, for example:
request.body.serverValue['code']
but that value it seems is generated at compile time, perhaps to enable the auto-generation of tests in ContractVerifierTest.java under generated-test-sources.
Can this be done ? Is this an appropriate use of Spring Cloud Contract ?
Currently, it's not supported. We prefer an approach where you have simpler contracts. If you need in a response a value from the request just hard code both the request and the response parts of the contract.
You can, however, file an issue and we can try to think of something in the future releases.
UPDATE:
With version 1.1.0 that's already possible. Check out the docs for more info - http://cloud.spring.io/spring-cloud-static/spring-cloud-contract/1.1.0.RELEASE/#_referencing_request_from_response
We have a web application (AngularJS and Web API) which has quite a simple functionality - displays a list of jobs and allows users to select and cancel selected jobs.
We are trying to follow RESTful approach with our API, but that's where it gets confusing.
Getting jobs is easy - simple GET: /jobs
How shall we cancel the selected jobs? Bearing in mind that this is the only operation on jobs we need to implement. The easiest and most logical approach (to me) is to send the list of selected jobs IDs to the API (server) and do necessary procedures. But that's not RESTful way.
If we are to do it following RESTful approach it seams that we need to send PATCH request to jobs, with json similar to this:
PATCH: /jobs
[
{
"op": "replace",
"path": "/jobs/123",
"status": "cancelled"
},
{
"op": "replace",
"path": "/jobs/321",
"status": "cancelled"
},
]
That will require generating this json on client, then mapping it to some the model on server, parsing "path" property to get the job ID and then do actual cancellation. This seems very convoluted and artificial to me.
What is the general advice on this kind of operation? I'm curious what people do in real life when a lot of operations can't be simply mapped to RESTful resource paradigm.
Thanks!
If by cancelling a job you mean deleting it then you could use the DELETE verb:
DELETE /jobs?ids=123,321,...
If by cancelling a job you mean setting some status field to cancelled then you could use the PATCH verb:
PATCH /jobs
Content-Type: application/json
[ { "id": 123, "status": "cancelled" }, { "id": 321, "status": "cancelled" } ]
POST for Business Process
POST is often an overlooked solution in this situation. Treating resources as nouns is a useful and common practice in REST, and as such, POST is often mapped to the "CREATE" operation from CRUD semantics - however the HTTP Spec for POST mandates no such thing:
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. For example, POST is used for the following functions (among others):
Providing a block of data, such as the fields entered into an HTML form, to a data-handling process;
Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles;
Creating a new resource that has yet to be identified by the origin server; and
Appending data to a resource's existing representation(s).
In your case, you could use:
POST /jobs/123/cancel
and consider it an example of the first option - providing a block of data to a data handling process - and is analogous to html forms using POST to submit the form.
With this technique, you could return the job representation in the body and/or return a 303 See Other status code with the Location set to /jobs/123
Some people complain that this looks 'too RPC' - but there is nothing that is not RESTful about it if you read the spec - and personally I find it much clearer than trying to find an arbitrary mapping from CRUD operations to real business processes.
Ideally, if you are concerned with following the REST spec, the URI for the cancel operation should be provided to the client via a hypermedia link in your job representation. e.g. if you were using HAL, you'd have:
GET /jobs/123
{
"id": 123,
"name": "some job name",
"_links" : {
"cancel" : {
"href" : "/jobs/123/cancel"
},
"self" : {
"href" : "/jobs/123"
}
}
}
The client could then obtain the href of the "cancel" rel link, and POST to it to effect the cancellation.
Treat Processes as Resources
Another option is, depending on if it makes sense in your domain, to make a 'cancellation' a noun and associate data with it, such as who cancelled it, when it was cancelled etc. - this is especially useful if a job may be cancelled, reopened and cancelled again, as the history of changes could be useful business data, or if the act of cancelling is an asynchronous process that requires tracking the state of the cancellation request over time. With this approach, you could use:
POST /jobs/123/cancellations
which would "create" a job cancellation - you could then have operations like:
GET /jobs/123/cancellations/1
to return the data associated with the cancellation, e.g.
{
"cancelledBy": "Joe Smith",
"requestedAt": "2016-09-01T12:43:22Z",
"status": "in process"
"completedAt": null
}
and:
GET /jobs/123/cancellations
to return a collection of cancellations that have been applied to the job and their current status.
Example 1: Let’s compare it with a real-world example: You go to a restaurant you sit at your table and you choose that you need ABC. You will have your waiter coming up and taking a note of what you want. You tell him that you want ABC. So, you are requesting ABC, the waiter responds back with ABC he gets in the kitchen and serves you the food. In this case, who is your interface in between you and the kitchen is your waiter. It’s his responsibility to carry the request from you to the kitchen, make sure it’s getting done, and you know once it is ready he gets back to you as a response.
Example 2: Another important example that we can relate is travel booking systems. For instance, take Kayak the biggest online site for booking tickets. You enter your destination, once you select dates and click on search, what you get back are the results from different airlines. How is Kayak communicating with all these airlines? There must be some ways that these airlines are actually exposing some level of information to Kayak. That’s all the talking, it’s through API’s
Example 3: Now open UBER and see. Once the site is loaded, it gives you an ability to log in or continue with Facebook and Google. In this case, Google and Facebook are also exposing some level of users’ information. There is an agreement between UBER and Google/Facebook that has already happened. That’s the reason it is letting you sign up with Google/ Facebook.
PUT /jobs{/ids}/status "cancelled"
so for example
PUT /jobs/123,321/status "cancelled"
if you want to cancel multiple jobs. Be aware, that the job id must not contain the comma character.
https://www.rfc-editor.org/rfc/rfc6570#page-25
How may I include, using JsonApi, links to methods in my Rest API?, for example I have something like this:
POST api/v1/customer/1/deactivate
POST api/v1/customer/1/activate
To activate and deactivate a customer correspondingly. How they should be included (or not) in my data object? The specification does not include something like "methods" section for the data object.
Updating based on your change and based on guillaume31's answer.
If it is truly an update to a resource then you should issue a PATCH to:
api/v1/customer/1
And with a jsonapi compliant body to update the resource:
{
"data": {
"type": "customer",
"id": "1",
"attributes": {
"status": "deactivated"
}
}
}
If the intent is to truly remove the resource then a delete may be more appropriate. Based on your description the PATCH may be the best path since the resource is still present and may be restored based on other calls
POST api/v1/customer/1/deactivate
POST api/v1/customer/1/activate
This is not RESTful. But the "active" state of a customer can be seen as a resource! So the simplest solution is the following:
PUT api/v1/customer/1/active # Activates customer 1
DELETE api/v1/customer/1/active # Deactivates customer 1
The PATCH solution described by #guillaume31 is also a valid approach, but implementing RESTful PATCH correctly requires that the change is described with operation, data pointer and new value (see also the JSON Patch RFC). That's probably overkill for this simple scenario.
By including "deactivate" as part of the URI, you're kind of making deactivate a resource, which seems incorrect. This IMO isn't REST level 1 compliant.
As I understand it, activating/deactivating a customer amounts to updating a resource. JsonApi recommends sending a PATCH request to modify a resource : http://jsonapi.org/format/#crud-updating
However, it would perhaps be more faithful to REST to model activation as a POST or a PUT and deactivation as a DELETE. You would benefit from PUT and DELETE's idempotency -- activating or deactivating a customer twice in a row should probably leave it in the same state. But it also depends on your domain and what consequences these actions have.
In the REST frameworks I know, verbs are not included in links out of the box. I doesn't seem to be the case with JSON API either.