I'm developing a jQuery website that will display a single record from my Azure Table Storage (ATS) account. I don't want to use jQuery to directly access the table, since that would require disclosure of my ATS account name and key in the jQuery code. I've tried to find a simple C# web service example project that would be the interface, but everything I can find is much more complicated than I need.
This web service will need just one API that jQuery will use: it will be passed two strings: the Partition Key and the Row Key for ATS, which will exactly match with an existing record in ATS. The result returned will be a string that jQuery will convert using JSON.parse() after it is received. If no record is found with the Partition and Row Keys passed in, an empty string should be returned.
If you know of an example of a simple C# web service that I could use as a starting point, I would greatly appreciate a link to it. It's been many years since I developed with C#, and the complicated nature of the table service API with all the associated crypto, hashing, signatures, etc. have left me confused.
Edit: I now realize that maybe both my jQuery code (providing the web UI) and the C# (providing the ATS interface) might work together in one .NET solution. I'm currently running the jQuery UI app standalone in its own .NET solution, due to my path of fumbling around trying things out.
I don't want to use jQuery to directly access the table, since that would require disclosure of my ATS account name and key in the jQuery code.
It seems that you do not want jQuery client directly make a GET request to query entity via table service Rest API, and you’d like to create a backend service for querying entity in table. As maccettura mentioned in comment, you can create a ASP.NET Web API project and do Query Entities operation in controller action.
[Route("queryentity/{pk}/{rk}")]
public CustomerEntity Get(string pk, string rk)
{
//you can install [Azure Storage Client Library for .NET](https://www.nuget.org/packages/WindowsAzure.Storage/)
//and then create a retrieve operation and pass both partition and row keys to retrieve a single entity
//TableOperation retrieveOperation = TableOperation.Retrieve<CustomerEntity>(pk, rk);
//or
//make [Query Entities](https://learn.microsoft.com/en-us/rest/api/storageservices/query-entities) operation as you did
return myCustomerEntity;
}
Related
We are running an App with a Angular/Typescript frontend and a .NET backend, using Stripe Elements and Stripe.NET respectively.
We are currently using the "Sources" API.
The frontend can create sources, the backend saves them to our specific users. When you open the frontend again, the backend sends a list of source ids. The frontend then collects the data it needs to display those sources directly from Stripe so the user can pick one of his saved sources to pay and does not have to enter all the data again.
Enter the Payment Method / Payment Intend API.
Due to EU regulations Stripe has a new API that requires us to create cards no longer as "source" but as a "PaymentMethod". So I implemented that in the backend, opened the frontend in my IDE, updated the #types/stripe-v3 package and found the new payment intent API.
The only thing missing: I cannot figure out how the frontend is to access the payment method data, once created. I can create it. Send it to the backend. The backend can retrieve it. Send back the ID to the frontend... and now what? How to display the payment methods available?
I had expected a stripe.retrievePaymentMethod() as there is a stripe.retrieveSource(). But no such luck.
The only option I currently see to present the user with a list of existing payment methods is getting this info on the backend and piping it all, class by class, property by property to the client. Basically copying every single data class stripe has into our own backend REST definition. That cannot be right.
What am I missing? Why is there no stripe.retrievePaymentMethod() on the frontend? Did I not understand some fundamental facts about what those APIs should do?
After contacting Stripe directly, it was confirmed that that's just the way it is:
I think it's just an oversight that we didn't add one.
There are similar functions in the mobile SDK so I don't see why we shouldn't have it
There are no immediate plans to add the functionality back in in the very near future,
so as a workaround, I will tunnel all the data through our backend(s).
If I understand as well, I think your problem is following and the sequence of that. I hope this helps you.
I have implemented a payment gateway like ccAvenue with DotNet and angular, in my case, I send the data to the server, and from the server, I tried to redirect to the payment gateway, but APIs return some result, and the result can not be redirected.
So I created a web-form with implementation, I redirected my app to web-forms page and from there I called the ccAvenue page, and in the response URL, I send the response page of webforms only and after saving the response I redirected to my angular app.
Here is workaround if you want to process 3Dsecure cards and still support other methods like SEPA.
You could attach both, confirmed PaymentIntent (payment method) or Source to the Customer object.
On your frontend you could implement both (StripeElements with client secret for 3Dsecure cards) and IBAN element for SEPA.
I could provide my code example how I save payment intent to the customer. It's in PHP, but for other languages logic should be the same.
Assuming that our client already confirmed PaymentIntent and we have it's id:
$intent = \Stripe\PaymentIntent::retrieve($stripe_intent_id);
$payment_method = \Stripe\PaymentMethod::retrieve($intent->payment_method);
$stripe_customer = Stripe\Customer::create([
'payment_method' => $intent->payment_method,
]);
In case you've already created Customer object before you could use attach method:
$payment_method->attach(['customer' => 'cus_FTkGe4lv5LfyI0']);
Then you'll be able to charge using Customer object PaymentMethod or Source;
I didn't try to attach both methods to the same customer object (we only allow customer to have one payment option at the same time), but it should work. Let me know if it works for you.
We're thinking about an architecture for our next app and we're having problems with pass the tokens between apis. We'll have:
Front -->(call to) own login api (if all is ok we create an own token, named ownToken) -->(call to) third party api --> returns a JWT token (named 1token) -->
After everything is ok :
Front --> User do some tasks-->(With ownToken Call to) own business api (If ownToken is ok, do some stuffs)--> (with the 1token Call to) third party api (return some stuffs) --> Show information to the user.
We want to avoid calling the third party api every time that we want information from that api, but also we don't want to show that JWT to the user (I mean localstorage,sessionstorage...).
For more information, we'll use c# language and sql server as database.
Our question:
How do you mantain 1token between APIs?
you have two different things which need to be managed:
JWT-secured calls between your front-end and your back-end
JWT-secured calls between your back-end and a 3rd party.
What I would do is simply generate a 'sessionId' in the back-end which is part of the token you send to your front end. this could be an int or guid or whatever.
I would then associate this 'sessionId' with the token retrieved from the 3rd party and store that somehow - some form of database or file storage (DB would be the obvious thing to use).
That way whenever a request comes in from your front end in your back-end code you should:
Extract sessionId from the token they provide
lookup the entry for this Id in your database to get the token associated with it
use this token to make whatever calls are required and respond
You'd have to make sure to update this association whenever you need to get new tokens, but that shouldn't be too hard.
You could also use this to make the nature of the thing a bit more async - you could return immediately to your front end with a response suggesting it's 'Working On It' then the front end could call a separate endpoint later to get the results... That way if the 3rd party link takes a while then the original request isn't left waiting too long for a response...
I have a business logic which has lot of DB fetch operations and a bit complex business logic.
Data fetched is rarely changed within the session of user.
Many Fetch opertaions(data fetched is rarely changed within the session of user).
For each and every action on the form(button click/ value change in Textbox etc...) we need to run the business logic to check if it's valid change.
Currently we are using Asp.net Forms Application and these business logic is in InSessionScope().
Currently we are working on migrating to Restful API(WebAPI).
Can we use sessions(InSessionScope()) in RESTFul?
If not in sessions how to avoid more database calls and use the same object on subsequent calls and increase performance?
Based on my personal experience NEVER use Session in a Rest Application as AspNET WebAPI are .. even if you can .. but instead use Tokens for Authorization and User Profilation (with AspNet Identity) and for performance (don't hit DB too many times) i suggest to you some ways as i have done:
1 - USE CACHE!! (there are some great frameworks and lib for cache ..you can use different Layers of cache .. Query .. Response of webapi ..for example I'm use to cache the entire API response (Json) and auto invaildate it on POST / PUT / DELETE request) ..in .NET you can use this https://github.com/filipw/Strathweb.CacheOutput
You can also use Redis for caching (if you don't want to cache locally in the Server but to have a distribuited cache)
2 - Try to think in NoSQL way .. in our application we use a mix of DB .. SQL Server but also MongoDB (expecially for big amount of data ) for example we use SQL server to manage AspNEt Identity but we use MongoDB to store our Product (we have about 6 milions of products) and it take about 1 sec for query (also with aggregation!!) ..
3 - Try to use LocalStorage on the FrontEnd if you can to store some information. .and then sync them when you need ..
Hope it can help you.. enjoy WebAPI ..enjoy REST!! (and leave webforms as soon as you can ...in my idea!!)
You can use tokens implemented by you or JwtToken.
If you choose implement custom token on login method you must return a token to you app, next in any api call pass this token like a header or query string and decrypt in server to validate propose.
Let's assume we have a RESTful web service that will calculate UK Royal Mail postage charges.
There would be a number of essential input parameters:
weight of item (grams, int),
length of item (cm, int),
width of item (cm, int),
category of item (letter/parcel, string/enum),
service required (first class/second class/special delivery/etc, string/enum),
destination (domestic/international/maybe further specify the latter, string/enum)
Such an application would be easy to create as a WebAPI. It could be called via a URL such as ...
http://myserver.com/api/mailcharges?weight=150&length=15&width=10&category=letter&service=first&destination=domestic
The web service would then do a simple lookup on its internal tables and return the postage in its response payload.
The beauty of this is that it could then be utilised by a variety of applications within an organisation (or even outside it!). However, this requires that each application that calls the web service needs to be able to populate these parameters; the integers are OK, they are just that - numbers. But the strings or enums are more difficult. The logic for entering and validating these needs to be replicated in every client application. Wouldn't it be nicer if the web service could prompt the user for any which are not passed in or passed as nulls or invalid values. In fact wouldn't it be nicer still if the web service had a user interface which allowed a user to enter any or all of the parameters.
What I am looking for is a cross between a web site and a web service. A web application which can be called via a simple RESTful http request, which pops up a user dialogue, accepts user input, and when the user clicks on a suitable button, does its calculation and returns its answers as a JSON/XML response.
Does anyone have any ideas on how to implement such an architecture? I have tried calling MVC actions/views from within a web api controller but the response is the html for the MVC view, and is returned to the api controller directly rather than being rendered and POSTing back its user input.
I hope I am just being thick, and that the answer is obvious, but all my experiments have so far failed, and any suggestions, no matter how far fetched or outrageous, would be very welcome.
I realize that this is a fairly trivial example, but the same argument goes for much more complicated web services where the replication of user input forms, input validation, complex processing logic etc. across multiple client applications would be far more of an issue than with this example.
if the web service could prompt the user is essentially missing the point of a service. It is no longer a webservice, but a webpage.
In order for internal/external applications/websites to utilize your service, they essentially need to know three things:
where to ask - this is your http://myserver.com/api/mailcharges
what are the arguments - that is weight, length…
what are accepted argument values
While 1. and 2. are usually mere API documentation you seem to have a problem with p. 3 - you want the user to be somehow prompted to choose among possible values and not guess. But you also want the user application not to be responsible for maintaining/validating the list of possible values.
Guess what? You simply need another API. :) An API to describe your arguments.
Let's concentrate on category field. Your API could be extended with a new URL: http://myserver.com/api/getCategories which essentially returns a list of available (currently understood by API) possible category values. This can be JSON, or comma separated string or whatever reliable. Now your end-user GUI-enabled application calls the API, asks for categories, and creates UI accordingly - populating ComboBox or whatever with obtained values. The same is done for other fields. You can. i.e. obtain acceptable ranges of weight or length.
The important thing you mention in your question is validation: logic for entering and validating these needs to be replicated in every client application. This is somehow true, as it essentially depends on the technology used in the end-user application. On the other hand it is very important, that the API performs validation itself! You can never know who is going to use your API. And it is always better to check twice then never.
I have a problem here. Assume there's a basic calculator implemented in javascript hosted on a website ( I have googled it and to find an example and found this one: http://www.unitsconverter.net/calculator/ ). What I want to do is make a program that opens this website, enters some value and gets the return value. So, in our website calculator, the program:
- open the website
- enters an operand
- enters an operation
- enters an operand
- retrieve the result
Note: things should be done without the need to show anything to the user ( the browser for example ).
I did some search and found about HttpWebRequest and HttpWebRespond. But I think those can be used to post data to the server, which means, The file I'm sending data to must be php, aspx or jsp. But Javascript is client side. So, I think they are kind of useless to me in this case.
Any help?
Update:
I have managed to develop the web bot using WebBrowser Control tool ( found in System.Windows.Forms )
Here's a sample of the code:
webBrowser1.Navigate("LinkOfTheSiteYouWant"); // this will load the page specified in the string. You can add webBrowser1.ScriptErrorsSuppressed = true; to disable the script in a page
webBrowser1.Document.GetElementById("ElementId").SetAttribute("HTMLattrbute", "valueToBeSet");
Those are the main methods I have used to do what I wanted to.
I have found this video useful: http://www.youtube.com/watch?v=5P2KvFN_aLY
I guess you could use something like WatiN to pipe the user's input/output from your app to the website and return the results, but as another commenter pointed out, the value of this sort of thing when you could just write your own calculator fairly escapes me.
You'll need a JavaScript interpreter (engine) to parse all the JavaScript code on the page.
https://www.google.com/search?q=c%23+javascript+engine
What you're looking for is something more akin to a web service. The page you provided doesn't seem like it accepts any data in an HTTP POST and doesn't have any meaningful information in the source that you could scrape. If for example you wanted to programmatically make searches for eBay auctions, you could figure out how to correctly post data to it eg:
http://www.ebay.com/sch/i.html?_nkw=http+for+dummies&_sacat=267&_odkw=http+for+dummies&_osacat=0
and then look through the http response for the information you're looking for. You'd probably need to create a regular expression to match the markup you're looking for like if you wanted to know how many results, you'd search the http response for this bit of markup:
<div class="alt w"><div class="cnt">Your search returned <b>0 items.</b></div></div>
As far as clientside/javascript stuff, you just plain aren't going to be able to do anything like what you're going for.
It is a matter of API: "Does the remote website expose any API for the required functionality?".
Well web resources that expose interactive API are called web service. There are tons of examples (Google Maps for istance).
You can access the API -depending on the Terms & Conditions of the service- through a client. The nature of the client depends on the kind of web service you are accessing.
A SOAP based service is based on SOAP protocol.
A REST based service is based on REST principles.
So, if there is an accessible web service called "Calculator", then you can access the service and, for istance, invoke the sum method.
In your example, the calculator is a Javascript implementation, so it is not a web service and it cannot be accessed via HTTP requests. Though, its implementation is still accessible: it is the javascript file where the calculator is implemented. You can always include the file in your website and access its functions via javascript (always mind terms and conditions!!).
A very common example is the jQuery library stored in Google Libraries.