I'm using Charles' Rewrite Tool to change 200 responses to 400 in order to test failing API calls. However, the rewrite is triggering on the Options request. I'd like to only have it trigger on the Get or Post requests and allow the Options requests through. Is this possible using Charles?
We were able to work around the issue by assuming that OPTIONS would always return an empty body.
The below Regex values will match for GET (because it has a response body) and not match for OPTIONS (because it doesn't have a response body).
\{[\S\s]*\}
or
\[[\S\s]*\]
I think Charles does not have this option, which is really a pitty, because it seems to be easy to implement and it would open the doors to the API world.
I would suggest you to ask Karl (the author and main developer) for this new feature at the contact section of the site.
We have this exact same need to mock API responses. Since the Rewrite tool doesn't support this feature, we have setup Breakpoints on the responses we want to mock, once the breakpoint is hit, we change the response to whatever we want. It works, but is less than ideal.
Unfortunately, Charles doesn't have this feature to filter out which the Request that has certain HTTP Method.
It's not a direct answer, but you can achieve with Scripting tool from Proxyman
function onResponse(context, url, request, response) {
// Update status Code
response.statusCode = 500;
// Done
return response;
}
Here is the Snippet Code that you can do with JS Code.
Disclaimer: I'm a creator of Proxyman. Since there are many people who struggle with this problem, hopefully, the Scripting tool can help you.
In Charles, you can use Breakpoints tools. FYR: https://tanaschita.com/20220307-manipulating-network-requests-and-responses-with-charles/.
Related
As far as I understand, in a CQRS-oriented API exposed through a RESTful HTTP API the commands and queries are expressed through the HTTP verbs, the commands being asynchronous and usually returning 202 Accepted, while the queries get the information you need. Someone asked me the following: supposing they want to change some information, they would have to send a command and then a query to get the resulting state, why to force the client to make two HTTP requests when you can simply return what they want in the HTTP response of the command in a single HTTP request?
We had a long conversation in DDD/CRQS mailing list a couple of months ago (link). One part of the discussion was "one way command" and this is what I think you are assuming. You can find out that Greg Young is opposed to this pattern. A command changes the state and therefore prone to failure, meaning it can fail and you should support this. REST API with POST/PUT requests provide perfect support for this but you should not just return 202 Accepted but really give some meaningful result back. Some people return 200 success and also some object that contains a URL to retrieve the newly created or updated object. If the command handler fails, it should return 500 and an error message.
Having fire-and-forget commands is dangerous since it can give a consumer wrong ideas about the system state.
My team also recently had a very heated discussion about this very thing. Thanks for posting the question. I have usually been the defender of the "fire and forget" style commands. My position has always been that, if you want to be able to move to an async command dispatcher some day, then you cannot allow commands to return anything. Doing so would kill your chances since an async command doesn't have much of a way to return a value to the original http call. Some of my team mates really challenged this thinking so I had to start thinking if my position was really worth defending.
Then I realized that async or not async is JUST an implementation detail. This led me to realize that, using our frameworks, we can build in middleware to accomplish the same thing our async dispatchers are doing. So, we can build our command handlers the way we want to, returning what ever makes sense, and then let the framework around the handlers deal with the "when".
Example: My team is building an http API in node.js currently. Instead of requiring a POST command to only return a blank 202, we are returning details of the newly created resource. This helps the front-end move on. The front-end POSTS a widget and opens a channel to the server's web socket using the same command as the channel name. the request comes to the server and is intercepted by middleware which passes it to the service bus. When the command is eventually processed synchronously by the handler, it "returns" via the web socket and the front-end is happy. The middleware can be disabled easily, making the API synchronous again.
There is nothing stopping you from doing that. If you execute your commands synchronously and create your projections synchronously, then it will be easy for you to just make a query directly after executing the command and returning that result. If you do this asynchronously via the rest-api, then you have no query result to send back. If you do it asynchronously within your system, then you can wait for the projection to be created and then send the response to the client.
The important thing is that you separate your write and read models in classic CQRS style. That does not mean that you cannot do a read in the same request as you do the command. Sure, you can send a command to the server and then with SignalR (or something) wait for a notification that your projection have been created/updated. I do not see a problem with waiting for the projection to be created on the server side instead for on the client.
How you do this will affect you infrastructure and error handling. Also, you will hold the HTTP request open for a longer time if you return the result at once.
I'm using SailsJS 0.9.8 and I would like to add some information to each API response if the response should go to a websocket.
The reason I want to do this is that the application makes use of websockets a lot via socketIO and when using the send() and json() methods of the response object the status code is not added to the json that is sent to the socket which is otherwise available if sending via http. I could just add the status to the json before sending but it would get messy so I would like to do it some other way.
Some of the response methods, like badRequest() and serverError() etc, do add the expected status code but send() and json() do not, even if I give it as a parameter. Is it possible to change this behaviour?
P.S. I did look at this question which is basically the same as my question but the chosen answer didn't work for me, i copied the source files for badRequest and put it in api/responses/ and simply added a printout but it never showed.
Thanks
I know that this is supported in sails.js 0.10.x: http://sailsjs.org/#/documentation/concepts/Custom-Responses
I've got a Backbone web application that talks to a RESTful PHP server. For PUT and POST it matters in which order the requests arrive at the server and for GET it matters in which order the responses arrive at the client.
The web application does not need to be used concurrently by multiple users, but what might happen is that the user changes its name twice really fast. Then the order in which the server processes PUT /name/Ann and PUT /name/Bea determines whether the name is set to Ann or Bea.
Backbone.Safesync and Backbone.Sync.AjaxQueue are two libraries that try to solve this problem. Doesn't Safesync only solve the problem with GET? Sync.AjaxQueue is outdated, but might serve as inspiration to implement a custom queued sync function. Making sync synchronous would solve the problem. If a request is only sent after the previous response is received, then only one request is processed at a time.
Any advice on how to proceed?
BTW: I don't think using PATCH requests would solve anything, because in my example the same attribute is changed twice.
There's a few ways to solve this, here's two:
add a timestamp to all requests, store it in the DB as "modified" and let the server check whether the timestamp of the new request is later than the one in the DB in order to be valid
use Promises to delay the second request from being made before the first one is responded on, there's a promise/deferred mechanism built into jquery, but you can also use a 3rd party one, for instance Q or when
If you can afford the delay, an easy approach is to set the async option to false when you call whatever method you're calling that results in the Backbone.sync. For example, in the appropriate model(s) simply override the default sync method to include the additional option.
I what to do is to make a DELETE request using dispatch. I know how to use it in POST and GET, but it seems that I can't find samples on how to use DELETE?
:/("www.scala-lang.org").DELETE
where :/ constructs new request. Some code snippets are available here, just to help you get started.
I want to modify the response that is sent when I am implementing a SOAP server using Zend_Soap_Server. I want to change the response that will be sent back because I am implementing the SOAP server for a client application that was written to work with another system but now I need to make it work with our system. The client application is expecting the XML response to be in a certain way. So what I want to do is that I dont want the handle method to put together its own XML response, I want to do it myself. Can this be done?
Thanks
I suspect there is some kind of output buffering trick you could use to do this, but a better solution might be to investigate the deeper cause of why the client is rejecting your XML and, in so doing, you may find a much more elegant solution.
For starters, you should probably read this very helpful article:
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
You should then investigate Zend_Soap_AutoDiscover->setOperationBodyStyle() and Zend_Soap_AutoDiscover->setOperationBodyStyle() to see if changing the encoding style or binding style solves the problem.