I'm attempting to create mock api services for testing purposes. We are already using Apiary on another team so I'm starting there.
So far, I've noticed that if I want to have two separate calls requires mocking out of both requests. For example to get the notes with ids 1 and 2 requires explicitly writing out responses like:
/notes/1
/notes/2
Is there a way to avoid this? Admittedly I'm still ramping up on creating blueprints.
Have a look at private-e9e59-pingdomcheck.apiary-mock.com/v1/gists/1. The number 1 is {id} here. You of course get only the general defined response (like if I used id 42).
There are more things being done right now in MSON. Once it's released, different replies for different parameters in request will be possible.
Related
I have a ruby pact mock service provider that captures my request. I would like to extract the exact value provided in the request (which was matched by a Pact.term / Pact.like), to do further processing with that value once the request has been answered by the pact service provider.
An example: a password reset functionality. Code makes an API call to a mailing service, providing the password reset link as parameter. Pact captures the request and mocks it successfully, validating the data. I pass the reset_link as one of the parameters (a Json body). This gets match in a Pact.term. All good. But I also want to recover the exact value that was used in the request (say reset_link: 'http://sample.com/reset-password?key=12345'), so I can make a subsequent request and check that exact link does indeed allow a successful password reset.
Now, if I was sending email directly, it is easy to do, I can just parse Mail::TestMailer.deliveries.last
How can I do this?
I've gone through the code, even creating a Pact::SomethingLike subclass wouldn't work, as the comparison method is a lovely functional programming module, not a method in the class.
Is there a before / after hook, or a way to grab the whole web request?
PS: I'm aware this is typically tested by the underlying library I use. The library sanctioned way of adjusting functionality is to override certain methods, I need to re-test the whole functionality.
PPS: this is not rails but roda.
Thanks
André
I'm not sure if Pact Ruby supports this exact requirement, however digging into why you're doing this, I'd suggest it's a bad idea.
This is a functional test, something that Pact consciously makes difficult to support. See https://docs.pact.io/best_practices/contract_tests_not_functional_tests.html for more details as to why. There are better tools for the job for these sorts of tests, and they don't belong in the consumer code base (they absolutely do belong in the Providers' test suite).
Pact is a contract testing tool, and as such is only interested in isolated request/response contracts, not chained ones as per functional tests.
I'm working on a web application that need to expose Json API for external apps and I'm planning to do an API centric architecture.
So basicly, the app will juste contains view/controllers for the web interface. the controllers will use Route::dispatch to create a request to the api part of the site (another controller in a package, but in the same laravel installation), then parse the result, and create view accordingly.
So I'm wondering what are the drawbacks, performance wise, of using this sort of architecture?
If each controller is writing the logic to internally dispatch another request then I'd consider abstracting that away from the controller and in to your own dispatcher. I doubt there would be a huge performance overhead. The application (as far as I know) doesn't get booted twice so you don't have to worry about that.
The only thing you need to be aware of is the input for the main request being used. Something you should take into account inside your dispatcher. Refer to this answer for more information.
You can also read more on consuming your own API.
Do I need to send individual entity updates to WebAPI, or can I POST an array of them and send them all at once? It seems like a dumb question, but I can't find anything that says one way or another.
Brad has a blog post that talks about implementing batching support in Web API.
Also, Web API samples project on codeplex has a sample for doing batching in web API hosted on asp.net.
It seems like WEB API 2 has support for this
From the site (Web API Request Batching):
Request batching is a useful way of minimizing the number of messages
that are passed between the client and the server. This reduces
network traffic and provides a smoother, less chatty user interface.
This feature will enable Web API users to batch multiple HTTP requests
and send them as a single HTTP request.
There are a number of samples for different scenarios on this page.
https://aspnetwebstack.codeplex.com/wikipage?title=Web+API+Request+Batching
You will have to create an action that accepts a collection of items.
If all you have is an action that accepts a single item than you need to send separate requests.
With batching always think about how you would report the failures and whether a failing of a single item should invalidate the whole batch.
I am trying to make a web app using ExpressJS and Coffeescript that pulls data from Amazon, LastFM, and Bing's web API's.
Users can request data such as the prices for a specific album from a specific band, upcoming concert times and locations for a band, etc... stuff like that.
My question is: should I make these API calls client-side using jQuery and getJSON or should they be server-side? I've done client-side requests; how would I even make an API call from the server side?
I just want to know what the best practice is, and also if someone could point me in the right direction for making server-side API requests, that would be very helpful.
Thanks!
There's are two key considerations for this question:
Do calls incur any data access? Are the results just going to be written to the screen?
How & where do you plan to handle errors? How do you handle throttling?
Item #2 is really important here because web services go down all of the time for a whole host of reasons. Your calls to Bing, Amazon & Last FM will fail probably 1% or 0.1% of the time (based on my experiences here).
To make requests users server-side JS you probably want to take a look at the Request package on NPM.
It's often good to abstract away your storage and dependent services to isolate changes and offer a consolidated and consistent web api for your application. But sometimes, if you have a good hypermedia web api (RESTful responses link to other resources), you could reference a resource link from another service in the response from your service (ex: SO request could reference gravatar image/resource of user). There's no one size fits all - it depends on whether you want to encapsulate the dependency or integrate with it.
It might be beneficial to make the web-api requests from your service exposed via expressjs as your own web-apis.
Making http web-api requests is easy from node. Here's another SO post covering that:
HTTP GET Request in Node.js Express
well, the way you describe it I think you may want to fetch data from amazon, lastfm and so on, process it with node, save it in your database and provide your own api.
you can use node's http.request() to fetch the data and build your own rest api with express.js
I am creating a web service which uses REST web services. The client side code is written in HTML/JavaScript. My dilemma is whether I
should use the REST resource directly using AJAX calls?
or
should I create Servlets/JSPs (where REST calls will be made and data will be sent to client(AJAX/JAVSCRIPT)).
I have seen many web apps which follow the 2nd procedure but seems to me that it's doing the same thing as 1st in an indirect way.
Is there any advantage of using 2nd procedure over first?
What is the standard way to use REST services by HTML/javaScript client?
Please let me know if I am even thinking in the right direction and if not please give your valuable insight.
You can use either approach but note that browsers will enforce the same-origin policy on scripts, so if the REST service lives on a different domain than the script you will need to use a servlet/script on the same domain as the script to proxy the call to the other domain. I suspect this is why you are seeing the second approach used.
A proxy/middle-man servlet may also be useful if not all of the response is needed; you could use the servlet to strip out information that is not needed by the JavaScript to reduce the amount of data sent to the browser.
Directly accessing the resource(s) via AJAX has the obvious benefit of less overhead and is IMHO the more elegant solution, however it is also important to note that not all browsers support PUT and DELETE requests natively.
To get around this, you'll likely want to support the common "_method" hack. This stackoverflow question mentions this approach.