How to mock third party API via EasyMock ?
Ex:
2 classes - Employee - our class, NPECustomer - Third Party class
Assume Employee has createCustomer method with the following code
createCustomer(Employee emp) {
NPECustomer customer = new NPECustomer();
customer.add
customer.finalize
more customer. method and it goes on...
Now the question is how to mock third party API via easy Mock
What are the alternate ways to solve the above problem if Mocking the third party API is not feasible or tedious
Mocking can be done for any object. for third party ad servers we can start mock servers. This resolves the problem.
Related
I am going to build application that shows real time data with React.
And I decided to use Pusher for real time data management.
I also trying to use open third party apis for getting data.
For example openweathermap for weather data.
My trouble is how can I know if the data from third party api is changed and let the Pusher know data is changed.
In one word, how can I make Pusher to connect third party apis?
Really want your help.
Thank you.
Maybe there is a system for it in Pusher but I don't know.
If it is possible for you, you can create a cron service that checks your 3rd API continually. But it has to be on a live service to run continually. If it detects any changes in the data, it can emit your client app by using Pusher, Socketio, etc.
Maybe the 3rd API provides this feature to you.
Is there any way to override identity server 4 token generation ? means a class or interface to get username and password to call an external services to get token then use it by identity server 4 ?
If I understand your question correctly then Yes, there are a couple of options.
You can create a custom ProfileService to call your external service when Claims are generated, you can then fetch data from you external service, then return a List<Claim> for the information you are interested in. You would write all that inside the GetProfileDataAsync(ProfileDataRequestContext context) method.
Then you register the profile service through identity server builder middleware
var identityServerBuilder = services.AddIdentityServer();
identityServerBuilder.AddProfileService<ProfileService>()
And when you use the access token i.e communication to a third party API, you can simply depend on HTTPContext to find a claim by name and get the value you need, i usually write a ClaimsProvider that has getter methods to return the claims i need and means i can mock it easily without having to consider mocking httpcontext. Something like this
It is possible to hook into the other parts of the lifecycle, check this for example: http://docs.identityserver.io/en/latest/topics/custom_token_request_validation.html I recommend that you read the documentation if this doesn't move you forward?
Have fun! :)
Scenario:
I have a Node and Angular web app.
It needs to call an external api (a third party service) for data (more specifically this: https://api.represent.me/api/questions/).
Question:
Is it better to make this external call from the Angular frontend: GET http://thirdpartyservice.com/api/data or have the frontend calling a same domain Node endpoint: GET http://example.com/node-backend-api which then calls GET http://thirdpartyservice.com/api/data which then fetches and processes the data from the third party api before passing it back to angular?
Thoughts:
I guess two api calls is less desirable, but it is on the same domain
so would this not really be an issue?
GETing from the Node side would be more secure (especially if secret
keys were used), and also mask the fact that a third party service is
used.
CORS stuff might get in the way if calling from the frontend.
Is context key here, e.g. calling font apis from the
frontend is probably best, but fetching and needing to process data
is probably better from the backend.
What do others recommend (and do) and are there any other for or against points to add to the 'thoughts' too?
It depends on what your 3rd party API requires.
If you need some credentials to call the API it's probably better to handle the call in backend because of security concerns.
If the API delivers time sensitive data, like some auto-complete information as you type, it might be good to not do the extra roundtrip to the backend and call it from the frontend.
You might create a subdomain which points to the 3rd party server,
like 3rdparty-api.yourdomain.com, this removes a lot of cross-domain issues. But this needs cooperation of your 3rd party provider.
So, there is no clear yes or no answer but it depends on the situation and focus of your API.
Your solution looks fine, the only thing that may get in your way is if the 3rd party API you are using provides any sort of analytics. If you call it from Node you will overwrite the Agent and IP information that would be gathered if you called from UI. Other than that, I believe making the request directly from UI could reduce a little bit the load on the server, but I don't know if that matters to you.
I would say we should also take care about code duplication. In your case you are all JavaScript, but that is not true for many others. So let's say I consume api.github.com so I will not want to make some calls from frontend and some from the backend, then I think creating a controller which will handle all of this is a good choice.
Except for the cases like any analytics or tracking software, an extra round trip is ok.
As #Wolffc said, this can also prevent sending access_token to the browser which may be misused.
I have to build an angularJS webapp and found many resource for best practice but there are still some questions that were not answered. I hope you can help me.
Question 1: Model
One thing is, where should i store my model and handle changes to it?
I found some different solutions but they were all for simple datastructures. I have something like User ---> Subscription ---> Device ---> HardwareReport. And this is just one branch of the datastructure tree.
My question is where should i store it so that every Controller can access the data.
Current solution:
Current solution would be, not to store the data structure but to have a service for every object type like UserService or SubscriptionService.
And every of these services handles the communication with the backend server and keeps the return value in a cache.
Downside:
If a controller needs for example all devices of the user it has to deal with all services and can't just go through the data-structure tree. What if one controller changes for example the device object of the user. How should i notify other controllers?
Question 2: lazy configure/instantiate services
Here is a part of the application.
I have an AppController, LoginController and a MapController.
And i have a BackendService which encapsulates the API-Calls and is used by UserService and SubscriptionService.
When i login into my webapp the LoginController uses the SessionService to verify the login data and receives an accessToken for the API.
This accessToken must be set in the BackendService to be added to the header.
But the BackendService is already injected in other services.
Current solution:
Just set the AccessToken from LoginController like
BackendService.setAuth(accessToken);
Because the service is singleton all other services that uses BackendService will be have the correct setup BackendService.
Downside:
I can call functions of the BackendService before setting the access token and this would result in errors.
** Alternative solution: **
I just implement a BackendServiceFactory which i can use at any time to create a new BackendService instance. So i can create the BackendService in the LoginController after login.
Downside: I have to pass this object through all my services and controller because it won't be injected by DI.
Quite long questions but i hope you can give me some suggestions how to build this app.
I just started using breeze.js, it looks wonderful, but there is something that makes me confused. I am a newbie, so I am sorry if my question is dumb, or does not make sense:)
In server side, I have some repositories and UoW, I am trying to create REST Service. But I want to consume this service from mobile devices like Android, IOS and also from my SPA (Thanks to John Papa for HotTowel).
My confusion is if I arrange my UoW according to Breeze like using EFContextProvider or saving changes by using
public SaveResult SaveChanges(JObject saveBundle)
{
return _contextProvider.SaveChanges(saveBundle);
}
instead of using
public void Commit()
{
//System.Diagnostics.Debug.WriteLine("Committed");
DbContext.SaveChanges();
}
1)Am I still going to be able to use my UoW methods (like savechanges) from my non-breeze controllers?
and
2)Am I still going to be able to use the Rest service from native applications in mobile devices(that does not use breezejs).
1) No you cant use breeze contextProvider.SaveChanges() in your other controllers.
contextProvider.SaveChanges(JObject saveBundle)
breeze server side expects saveBundle to be a json data created by breeze client side js.
2) Create any other webapi controller for REST with its own repository. You can't work with breeze's repository saveChanges without breeze client side js.
UPDATE:
Breeze is raising so fast, they now have a BreezeSharp project. It can be integrated into your .net application. See Jay Traband answer saving changes to breeze web api from c#
#Didar is correct to observe that the JObject saveBundle is specific to the POST body sent by a Breeze client using the Web API out-of-the-box data service adapters.
I want to let you know that a Breeze client saveChanges method call can update a conventional RESTy service with separate PUT/POST/DELETE/PATCH methods if that's what you want to do. You'll have to change the client-side "data service adapter" to one that understands your server API ... or more likely write one that matches the peculiarities of your API.
Writing a custom data service adapter not a newbie task to be sure. We'll be showing how to do it soon ... but it won't be a newbie task ... more an intermediate's task.
My point is that it is there to be done, it isn't hard, and you can take comfort that it will be within your capacity to write by the time you need it.
FWIW, none of the code you're showing actually conforms to repository or UOW patterns IMO. You're showing perfectly serviceable starter code ... code that gets you up and running with a minimum of fuss.
Once you get going, you'd refactor so that references to contextProvider are no longer in your controllers. They'd be wrapped in a repository or unit-of-work component of some sort.
That's a story for another day.