In Fiddler how can I slow down the response of a specific request only, while passing through the response from the server?
I'm aware I can simulate a slow speed for all requests - that's not what I want.
Using the AutoResponder with a specific rule forces me to choose what to respond with.
How can I use the "Latency" feature without modifying the response? Is this possible in Fiddler?
I understood your question that you want to delay either request or response time for a specific request.
You could do it with the FiddlerScript module by updating the oSession object.
onBeforeRequest
// Delay sends by 300ms per KB uploaded.
oSession["request-trickle-delay"] = "300";
onBeforeResponse
// Delay receives by 150ms per KB downloaded.
oSession["response-trickle-delay"] = "150";
You would also need to filter the correct request in the selected method.
Filtering
// Sample Rule: Break requests for URLs containing "/path/"
if (oSession.uriContains("/path/")) {
}
if (oSession.hostname == "some.hostname") {
}
if (oSession.url == "some.url") {
}
Additional info can be found here
Hope it helps
Rather than using the latency feature, you can enter *delay:5000 as the then respond with... command, instead of a file path.
I noticed that the rules are ignored with a blank response, so you can use the latency with a command/path of *action, which isn't a real action, but causes the rule to execute and the latency to take effect, in case you really want to use the Latency column.
Related
I have recently read the guide on implementing RESTful API's in Spring Boot from the official Spring.io tutorials website (link to tutorial: https://spring.io/guides/tutorials/rest/)
However, something in the guide seemed to contradict my understanding of how REST API's should be built. I am now wondering if my understanding is wrong or if the guide is not of as high a quality as I expected it to be.
My problem is with this implementation of a PUT method to update the status of an order:
#PutMapping("/orders/{id}/complete")
ResponseEntity<?> complete(#PathVariable Long id) {
Order order = orderRepository.findById(id) //
.orElseThrow(() -> new OrderNotFoundException(id));
if (order.getStatus() == Status.IN_PROGRESS) {
order.setStatus(Status.COMPLETED);
return ResponseEntity.ok(assembler.toModel(orderRepository.save(order)));
}
return ResponseEntity //
.status(HttpStatus.METHOD_NOT_ALLOWED) //
.header(HttpHeaders.CONTENT_TYPE, MediaTypes.HTTP_PROBLEM_DETAILS_JSON_VALUE) //
.body(Problem.create() //
.withTitle("Method not allowed") //
.withDetail("You can't complete an order that is in the " + order.getStatus() + " status"));
}
From what I read at https://restfulapi.net/rest-put-vs-post/ a PUT method should be idempotent; meaning that you should be able to call it multiple times in a row without it causing problems. However, in this implementation only the first PUT request would have an effect and all further PUT requests to the same resource would result in an error message.
Is this okay according to RESTful API's? If not, what would be a better method to use? I don't think POST would be any better.
Also, in the same guide, they use the DELETE method in a similar way to change the status of an order to cancelled:
#DeleteMapping("/orders/{id}/cancel")
ResponseEntity<?> cancel(#PathVariable Long id) {
Order order = orderRepository.findById(id) //
.orElseThrow(() -> new OrderNotFoundException(id));
if (order.getStatus() == Status.IN_PROGRESS) {
order.setStatus(Status.CANCELLED);
return ResponseEntity.ok(assembler.toModel(orderRepository.save(order)));
}
return ResponseEntity //
.status(HttpStatus.METHOD_NOT_ALLOWED) //
.header(HttpHeaders.CONTENT_TYPE, MediaTypes.HTTP_PROBLEM_DETAILS_JSON_VALUE) //
.body(Problem.create() //
.withTitle("Method not allowed") //
.withDetail("You can't cancel an order that is in the " + order.getStatus() + " status"));
}
This looks very wrong to me. We are not deleting anything here, it is basically the same as the previous PUT method just with a different state we want to move to. Am I correct to assume that this part of the tutorial is bogus?
TL;DR: what HTTP method is right to use when you want to advance the status of a resource to the next stage without giving an option of going back to an earlier stage? Basically an update/patch that will invalidate its own pre-conditions.
something in the guide seemed to contradict my understanding of how REST API's should be built. I am now wondering if my understanding is wrong or if the guide is not of as high a quality as I expected it to be.
I wouldn't consider this guide to be a reliable authority - the described resource model has some very questionable choices.
From what I read at https://restfulapi.net/rest-put-vs-post/ a PUT method should be idempotent; meaning that you should be able to call it multiple times in a row without it causing problems. However, in this implementation only the first PUT request would have an effect and all further PUT requests to the same resource would result in an error message.
The authoritative definition of idempotent semantics in HTTP is currently RFC 7231.
A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.
Note: "effect", not "response".
PUT /orders/12345/complete
means "please replace the current representation of /orders/12345/complete with the representation in the payload". In other words "save this file on top of your current copy". Saving the same file two or three times in row produces the same effect as saving the file once, so that's "idempotent".
HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how such storage might change as a result of a change in resource state, nor how the origin server translates resource state into representations. Generally speaking, all implementation details behind the resource interface are intentionally hidden by the server. -- RFC 7231
So in their CURL example
PUT /orders/4/complete HTTP/1.1
Host: localhost:8080
User-Agent: curl/7.54.0
Accept: */*
The meaning of this message is "replace the current representation of /orders/4/complete with an empty representation". But the origin server gets to choose how to do that, and which standardized responses to return to the client.
So this is fine.
All work is transacted by politely placing documents in in-trays, and then some side effect of placing that document in an in-tray causes some business activity to occur -- Jim Webber, 2011.
In this case, the document we are putting into the "in-tray" happens to be blank.
#DeleteMapping("/orders/{id}/cancel")
I would never approve that choice in a code review. DELETE (like PUT) has semantics in the "transfer of documents over a network domain".
The DELETE method requests that the origin server remove the association between the target resource and its current functionality. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation on the URI mapping of the origin server rather than an expectation that the previously associated information be deleted.
Trying to hijack the method because the spelling is kind of like the domain action is the wrong heuristic to use in choosing methods.
Relatively few resources allow the DELETE method -- its primary use is for remote authoring environments, where the user has some direction regarding its effect.
The point being that we have a general purpose document manipulation interface, and we are using that interface as a facade that allows us to drive business activity. So we should be using our standardized message semantics the same way every other page on the web does.
#PutMapping would be defensible, using the same justification as we did for /complete.
what HTTP method is right to use when you want to advance the status of a resource to the next stage without giving an option of going back to an earlier stage? Basically an update/patch that will invalidate its own pre-conditions.
PUT, PATCH, and POST are all appropriate methods to use when editing the representation of a resource. Use PUT or PATCH when you are sending a replacement representation for the resource, use POST when you are asking the server to calculate what the edit to the representation should be.
I'm currently using the PlayWS http client which returns an Akka stream. From my understanding, I can consume the stream and turn it into a Byte[] to calculate the size. However, this also consumes the stream and I can't use it anymore. Anyway around this?
I think there are two different aspects related to the question.
You want to know the size of the server response in advance to prepare buffer. Unfortunately there is no guaranteed way to do this. HTTP 1.1 spec explicitly allows transfer mode when the server does not know the size of the response in advance via chunked transfer encoding. See also quote from 3.3.1. Transfer-Encoding:
A recipient MUST be able to parse the chunked transfer coding
(Section 4.1) because it plays a crucial role in framing messages
when the payload body size is not known in advance.
Section 3.3.3. Message Body Length specifies how length of a message body is defined and it besides the aforementioned chunked transfer encoding it also contains quite unhelpful
Otherwise, this is a response message without a declared message
body length, so the message body length is determined by the
number of octets received prior to the server closing the
connection.
This is added for backward compatibility and discouraged from usage but is still legally allowed.
Still in many real world scenarios you can use Content-Length header field that the server may return. However there is a catch here as well: if gzip Content-Encoding is used, then Content-Length will contain size of the compressed body.
To sum up: in general case you can't get the size of the message body in advance before you fully get the server response i.e. in terms of code perform a blocking call on the response. You may try to use Content-Length and it might or might not help in your specific case.
You already have a fully downloaded response (or you are OK with blocking on your StreamedResponse) and you want to process it by first getting the size and only then processing the actual data. In such case you may first use getBodyAsBytes method which returns IndexedSeq[Byte] and thus has size, and then convert it into a new Source using Source.single which is actually exactly what the default (i.e. non-streaming) implementation of getBodyAsSource does.
I am looking into the Swift Vapor framework.
I am trying to create a controller class that maps data obtained on an SSL link to a third party system (an Asterisk PBX server..) into a response body that is sent over some time down to the client.
So I need to send received text lines (obtained separately on the SSL connection) as they get in, without waiting for a 'complete response' to be constructed.
Seeing this example:
return Response(status: .ok) { chunker in
for name in ["joe\n", "pam\n", "cheryl\n"] {
sleep(1)
try chunker.send(name)
}
try chunker.close()
}
I thought it might be the way to go.
But what I see connecting to the Vapor server is that the REST call waits for the loop to complete, before the three lines are received as result.
How can I obtain to have try chunker.send(name) send it's characters back the client without first waiting for the loop to complete?
In the real code the controller method can potentially keep an HTTP connection to the client open for a long time, sending Asterisk activity data to the client as soon as it is obtained. So each .send(name) should actually pass immediately data to the client, not waiting for the final .close() call.
Adding a try chunker.flush() did not produce any better result..
HTTP requests aren't really designed to work like that. Different browsers and clients will function differently depending on their implementations.
For instance, if you connect with telnet to the chunker example you pasted, you will see the data is sent every second. But Safari on the other hand will wait for the entire response before displaying.
If you want to send chunked data like this reliably, you should use a protocol like WebSockets that is designed for it.
I am developing 2 REST APIs which edits and pause something at my backend.
For editing I was using:
PUT /video/1
What is the best way to develop a pause video service. Should I use PATCH or PUT for this? Input would be just the id. If I use PUT then how can differentiate between edit and pause? And if I have another API to be developed for eg: video restart how can I accommodate these verbs in REST API?
Distinguishing the state using the HTTP method only is a poor idea. What you can is to:
Introduce state, and then use PATCH to change the state:
PATCH /vidoes/1
{
"state": "PLAYING|PAUSED|STOPPED" // what you need here
}
Mind don't patch like an idiot, however it is common to patch like an idiot.
Introduce new endpoints that will reflect the operation invoked on the resource - this is not fully RESTful, however also common:
POST /vidoes/1/play/
POST /vidoes/1/stop/
POST /vidoes/1/pause/
PUT for editing is ok of course, however remember that PUT is idempotent and requires the resource to be sent.
I do not agree with #Opal's answer here hence I post this answer. I do feel you use the wrong tools (or terms) to achieve what yo want. REST is more then just a HTTP invocation via a cleanly designed URI. As proposed by #Opal in a comment on his answer, WebSockets might be what you are looking for, though REST may be able to server your needs as well (as plain HTTP would do either).
Pausing a video
It should not be the task of the HTTP server to stop the video but the client. Usually partial GET requests are sent to the server retrieving only a portion of the resource and adding them to a buffer which the client reads. In the back the client site will issue further partial requests to keep the buffer filled while the client is reading it. If the client wants to pause, it simply stops reading the buffer and optionally stop sending further partial GET requests to the server.
This allows to spread the actual video onto mutliple servers and let the client talk to any of these and still get the correct responses. If the server has to maintain the client state, you need to ensure that the state is also replicated to all the other serving nodes. Sure, this is possible but also combined with higher overhead!
Updating videos
As you obviously create a video-editing system you have two options here as also suggested by the PUT definiton:
Partial content updates are possible by targeting a separately identified resource with state that overlaps a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for example, the PATCH method defined in RFC5789).
Separate the resource into smaller resources
Use an other method like PATCH
As already pointed out by #Opal in his answer, in case when you use PATCH to partially update a resource you should not only provide the new content within the body but also instruct the server what is should do with it.
The separation into smaller resources however does feel more natural to me for a video-editing system though. A video can be seen as a sequence of scenes which consist of numerous pictures and maybe an attached soundfile.
A movie therefore could be represented like this in pseudo Json-HAL:
Movie : {
title: The Matrix,
release_year: 1999,
actors: [Keanu Reeves, Laurence Fishburne, Carrie-Anne Moss, Hugo Weaving, Joe Pantoliano],
...
link: {
self: http://...,
...
},
embedded: {
Scenes : [
{
description: Trinity chased by police,
links: [
self: http://...,
video: http://.../scene01.vid
]
},
{
description: Thomas Anderson get notified to follow the white rabbit,
start_offset: 5091,
end_offset: 193920,
links: [
self: http://...,
video: http://.../scene02.vid
]
},
...
]
}
}
Instead of having all the bytes in one file you could maintain each scene separately. The movie representation combines the scenes to a full movie if played from scene 1 to scene n.
If now one scene is edited and the whole scene file should be replaced, using a simple PUT request is enough. If you want to trim the first or last few seconds off the video, you could introduce a start and stop offset for the respective scene and instead of reuploading the full scene again, you tell the client that it should start at the suggested offest or stop at the suggested position.
The client can use this parameters in the partial GET request to retrieve only the necessary bytes. This fields should then of course be modified via a PATCH command in order to prevent altering the video bytes or its URI. In order for a client to learn the total bytes of a video it can issue a HEAD request first to the URI and use the content length returned from the response
This, of course, screems for its own media-type, but this is what REST is actually all about. I don't know why so many misuse the REST-term for plain URI-design or think that a neat URI-API is more RESTful when REST doesn't care much about the URI layout actually.
I need your help with the gwt requestfactory
considering following scenario:
I get an existing entity (let's say a invoice) from the server:
InvoiceEntityProxy invoice = request1.getInvoice();
I want to make some changes, so I edit it with a new request:
InvoiceEntityProxy editableInvoice = request2.edit(invoice);
//make some changes to editableInvoice
Now I send the changes made with the second request to the server, to create a preview:
request2.createPreview(editableInvoice);
When the request is sent, the invoice proxy is frozen and I re-enable editing by assigning the proxy to a new request:
editableInvoice = request3.edit(editableInvoice);
If everything is okay, i want to update the proxy and send it to the server, using the latest request:
request3.update(editableInvoice);
But the changes never arrive on the server, because the latest request (request3) doesn't know anything about the changes made to the proxy assigned to the request2.
I thought about following solutions:
I could redo the changes on the latest proxy. But for that, I've to iterate over all attributes and set them again (not very friendly solution, because I've to adjust the method each time I add some attributes to the proxy)
Another approach would be to send the proyx without an id to the server and send the id as second parameter of the update-method. But this would be a shame, because not only the deltas would be sent to the server (which is one of the greate features of the requestFactory).
So what is the best and most common practice to let the request3 know about the changes already made to the proxy, when it was assigned to another request.
You simply forget to call fire(). Example
request2.createPreview(editableInvoice).fire();
Bear in mind that if the following request depend on the result of the previous one, you should put your code in the OnSuccess methode because the request is asynchronous
It's also possible to append multiple requests
EDIT
It important to use the same request for the edit and fire operations. So replace this line
request.update(editableInvoice);
with
request3.update(editableInvoice);
Nice! I found the solution for my problem.
I still have an instance of the original proxy, because the edit() method of the context always return a new instance of the proxy. So I save the original proxy before sending any request.
After each successful request, I re-enable editing the proxy by call the edit method again:
editableInvoice = request3.edit(editableInvoice);
Now the crux:
I can set the original proxy of a proxy, which is used to consider if it changed and what changed. This is done by using AutoBean and set the PARENT_OBJECT Tag like this:
AutoBean<InvoiceEntityProxy> editableInvoiceBean = AutoBeanUtils.getAutoBean(editableInvoice);
AutoBean<InvoiceEntityProxy> originalInvoiceBean = AutoBeanUtils.getAutoBean(originalInvoice);
editableInvoiceBean.setTag(Constants.PARENT_OBJECT, originalInvoiceBean);
On the next request all changed properties are send to the server again.
Thank you for your help and thank you for the hint with the AutoBean #Zied Hamdi
You also can use AutoBeans to duplicate the object before you start changing it. You can keep the original one untouched then request.edit() it and apply changes (introspection like changes) from the "dirty" object.
You'll maybe have to do some research on how to handle EntityProxies since they are "special AutoBeans" : I had to use special utility objects to serialize them to json (available in GWT). So there might be some special handling in doing a deep copy too.
There is an issue maybe with GWT keeping only one version of each EntityProxy (I never checked if it is global or only in the context of a request)