[Help] Rest API programming.

[shonay]

Good morning 
Appears no one understood my question this morning, Recently I got into REST api programming where I have to take in hidden parameters and pass them via POST. So my merchant can save the data into the database on thier own end 
Goes like this, I have an api that looks like this 

http://apiurl/api/section.php?pay=

Now here is what, it has hidden fields some of which looks like this :

Payee_account
Payment_ID
Payment_amount
Payment_units
Payer_name

Now bear in mind that these fields are hidden. 

Suppose I want to integrate it to a pascal application(winform) how do I go about this?

[rvk]

... Recently I got into REST api programming where I have to take in hidden parameters and pass them via POST. So my merchant can save the data into the database on thier own end
Goes like this, I have an api that looks like this

http://apiurl/api/section.php?pay=

Now here is what, it has hidden fields some of which looks like this :

If this URL provides a REST api it should also have documentation. AFAIK REST communicates though XML of JSON. So with that url you can post and get data back. None of that data is "hidden". So to what "hidden" fields are you referring?

It's best to give full information maybe with some examples.

[Thaddy]

First, @RVK, luckily REST is a programming model that does not rely on any content description protocol like XML (juck, I will shoot it if I have to) or JSON. That aside.

If you are referring to hidden fields it is most likely that these are server side only and therefor are not (meant to be) accessible for your clients. You can make them accessible by for example writing stored procedures that eventually produce the desired result and  can be posted back to the client side.
It is never a good idea to have (client side ) hidden fields not showing up in the rendered client side  pages. That is a security disaster for you. Don't rely on a browser on the other side. It may very well be simply a traffic analyzer posing as a browser. That would spot these hidden fields and depending on good or evil intent WILL exploit them.

Never ever maintain state (from your info) at the client side, i.e. don't use cookies in any form (which are in effect a sublimation of hidden fields) except for session maintenance, not database related stuff. But I am calling from being buried deep in the sands of a desert. And everybody knows the above is the case.
(Reason: every computer scientist knows state is often not necessary, client side state is evil and marketing/advertising is the only reason it still exists on the interweb.

[rvk]

First, @RVK, luckily REST is a programming model that does not rely on any content description protocol like XML (juck, I will shoot it if I have to) or JSON. That aside.

Yes, but we're not talking about "REST programming model" we're talking about a REST api implementation.

An api is an "application programming interface" and that one DOES rely on transfering data via HTML, XML or JSON.

Unlike SOAP-based web services, there is no "official" standard for RESTful web APIs. This is because REST is an architectural style, while SOAP is a protocol. Even though REST is not a standard per se, most RESTful implementations make use of standards such as HTTP, URI, JSON, and XML.

So if you're talking about an api, your not talking about the theoretical REST but about an actual data-transferring implementation.

And if there was an URL provided like http://apiurl/api/section.php?pay=, and it is said that it is a REST api implementation, there should also be documentation for using this. Without that documentation it's "just shooting in the dark".

It could just be a website shonay is accessing, but then that's not a REST api. (the REST api will be hidden from sight and hopefully protected to only accept data from the web-server)

[Thaddy]

First, @RVK, luckily REST is a programming model that does not rely on any content description protocol like XML (juck, I will shoot it if I have to) or JSON. That aside.

Yes, but we're not talking about "REST programming model" we're talking about a REST api implementation.

An api is an "application programming interface" and that one DOES rely on transfering data via HTML, XML or JSON.

Unlike SOAP-based web services, there is no "official" standard for RESTful web APIs. This is because REST is an architectural style, while SOAP is a protocol. Even though REST is not a standard per se, most RESTful implementations make use of standards such as HTTP, URI, JSON, and XML.

So if you're talking about an api, your not talking about the theoretical REST but about an actual data-transferring implementation.

And if there was an URL provided like http://apiurl/api/section.php?pay=, and it is said that it is a REST api implementation, there should also be documentation for using this. Without that documentation it's "just shooting in the dark".

It could just be a website shonay is accessing, but then that's not a REST api. (the REST api will be hidden from sight and hopefully protected to only accept data from the web-server)

That's a load of bull. an API should be written to be agnostic. unless you mean a contract about the exchange format. If you mean that? that's fine. Again some people do not know the difference between the actual theory and implementation detail. These are different universes. Don't confuse XML or JSON with REST.

And btw: https://en.wikipedia.org/wiki/Representational_state_transfer
I have more scientific info on request. But that wiki write up is pretty good. (Especially avoiding state on the client side)

The relevant citation is and relevant to the question:
"Stateless[edit]
See also: Stateless protocol
The client–server communication is further constrained by no client context being stored on the server between requests. Each request from any client contains all the information necessary to service the request, and session state is held in the client. The session state can be transferred by the server to another service such as a database to maintain a persistent state for a period and allow authentication. The client begins sending requests when it is ready to make the transition to a new state. While one or more requests are outstanding, the client is considered to be in transition. The representation of each application state contains links that may be used the next time the client chooses to initiate a new state-transition."

[rvk]

First, @RVK, luckily REST is a programming model that does not rely on any content description protocol like XML (juck, I will shoot it if I have to) or JSON. That aside.

Yes, but we're not talking about "REST programming model" we're talking about a REST api implementation.

An api is an "application programming interface" and that one DOES rely on transfering data via HTML, XML or JSON.

Unlike SOAP-based web services, there is no "official" standard for RESTful web APIs. This is because REST is an architectural style, while SOAP is a protocol. Even though REST is not a standard per se, most RESTful implementations make use of standards such as HTTP, URI, JSON, and XML.

So if you're talking about an api, your not talking about the theoretical REST but about an actual data-transferring implementation.

And if there was an URL provided like http://apiurl/api/section.php?pay=, and it is said that it is a REST api implementation, there should also be documentation for using this. Without that documentation it's "just shooting in the dark".

It could just be a website shonay is accessing, but then that's not a REST api. (the REST api will be hidden from sight and hopefully protected to only accept data from the web-server)

That's a load of bull. an API should be written to be agnostic. unless you mean a contract about the exchange format. If you mean that? that's fine.

Well, I think I was clear about mentioning the documentation of the API implementation. And I kept mentioning the IMPLEMENTATION (look at the number of times I mentioned implementation). So, yes, I'm talking about a contract about the exchange format.

[Thaddy]

We crossed some, but as I stated implicitly, that is not enough in the context of the question. I hope you agree. implementation can be faulty by implement. Specification can really be proven faulty by proving it scientifically wrong. (Falsifying versus verifying.)

I am relieved you were only talking about contract.

[shonay]

@rvk, of course yes it has to be hidden. Those parameters containing payment are hidden.
So hence I was thinking if I use wininet and POST to send the data over with the API so that it can submit to thier database? That's been giving me some sort of confusion, and again am asking if this can alternatively be done with a Pascal lazarus winform.

[rvk]

@rvk, of course yes it has to be hidden. Those parameters containing payment are hidden.
So hence I was thinking if I use wininet and POST to send the data over with the API so that it can submit to thier database? That's been giving me some sort of confusion, and again am asking if this can alternatively be done with a Pascal lazarus winform.

So I guess you mean the fields you're referring to are in an HTML-page of your webshop??
And you want to POST something (payment) to the same URL as the website is POSTing to?
Yes, that is possible with FPC/Lazarus providing that URL accepts POSTs from another location than the web-site itself. And if they do, it would be very very (and I mean very) insecure. If they do allow posting from any other location you would still need some documentation as to what exactly you need to POST. You could take all the fields on the website and POST that (and hoping that URL accepts it, and I hope for you it doesn't). But at least the Payment_ID for example needs to be created by the website (or underlying api implementation) so how would you retrieve that? If you have proper documentation you could communicate with your API to retrieve that, but without documentation your just guessing at what to do.

Maybe you should clarify what exactly you want to do in your Lazarus form (with what data) and about which payment service this is. That payment service should have documentation about retrieving start parameters about payment information and how you can POST information back to that service.

[shonay]

Ok
Maybe I make it straight and a bit clear.
It's something like a shopping cart interface, but here I have the api of the website and it uses POST to gather those parameters like I showed you earlier on.
Now the main duty is this. Suppose someone makes something like a payment of say £50, it gets the payment amount and then gathers the other hidden parameters, pass the information via POST request to the apiUrl, which in turn saves the data to the database.
Take a look at this c++ wininet method where they use this InternetOpen(), internetConnect()

This url explains https://support.microsoft.com/en-us/kb/165298

The httpsendrequest parameters is where I should then state the parameters of what I am sending.
Sorry if I confused you the more. But I know this should be the way of transmission of data. Kindly help.

[Thaddy]

Who are your payment providers? Or are you trying to be one yourself? (This is my line of work for the past 20 years, incl. contributions to the design and audit and approval of the most used internet payment system in the Netherlands (lest they forgot ) before it was there.)

Basically, you should have an interface to the payment provider (provided by them, they are standardized) which in essence sends you a true/false /approved/disapproved flag without any further state information about what you are selling. There is an exchange of information of what's the amount and a referral to the systems what they are in abstract but identifiable terms talking about.

You should just store the successful transaction and rely on your payment provider to store the payment details.

[shonay]

I'm selecting perfectmoney.
Now how do you use the winform to do it (not using web here)

[rvk]

I'm selecting perfectmoney.
Now how do you use the winform to do it (not using web here)

You did look at the documentation?
https://perfectmoney.is/sample-api.html

Specifically read perfectmoney-sci-2.0.doc and perfectmoney-api.doc first.

You should be able to create a form in Lazarus and POST data to the correct URL and let the user make a payment to another account.

To post data with httpsendrequest you could look at this answer:
http://stackoverflow.com/a/2977783/1037511

[rvk]

Specifically read perfectmoney-sci-2.0.doc and perfectmoney-api.doc first.

If you're done reading those documents I would advise you would first POST to https://perfectmoney.is/acct/verify.asp with the appropriate parameters to see if the transfer-data is correct. If you get a successful result, you can optionally show an intermediate form to confirm the transfer, and you can POST the data to https://perfectmoney.is/acct/confirm.asp to do the actual transfer.

[shonay]

I give it a shot sir. And get back to you this evening