I need to build a way to demo a REST API that takes three or four inputs, makes a REST call to an external server, then displays the response. This demo needs to be performed by a rather limited technical audience to business so REST clients are out.
It seemed like a simple HTML page that would do an ajax call would be fine for this, except I ran into the No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access fun messages because my localhost domain does not match the target domain. I don't have access to the target REST web service, so I can't make the necessary changes for the CORS headers.
Any ideas?
Build a very small and simple web application that shows the same HTML but does the REST call with its own REST client and shows the results.
Then run that on a local server.
Can you use a product where you can host your REST API? (There are number of API hosting products available. )If so you can try wso2 APImanager.? It is free and opensource. You do not need to develop any HTML page. You can try available swagger client or REST tool to test your APIs. You can do CORS settings too..
You can also use ExploREST, a project created with this goal in mind (production demo here).
With this tool, you can make GET/POST/PUT/DEL requests, but you can also create special links in the text documenting your API so that each time someone click on it, it will make the request you defined.
Example:
## My API is very good, I am documenting it. Try
%{
"text": "to post",
"post": {
"address": "/character",
"data": {
"name":"Dark Vador",
"type": "sith"
}
}
}%
Will result in a link that make a post when the user clicks on it.
The project is open source so do not hesitate to contribute !
Related
I have attempted to use the provided test data from the Cybersource documentation to create a token for a test PAN. However, when attempting to do so (assuming it was a REST Api) it results in a "403 - Forbidden" error. The documentation is limited, as it doesn't give much information on the API other than the following:
(Test) Endpoint: https://testsecureacceptance.cybersource.com/silent/token/create
Request to create a standalone payment token:
reference_number=123456789
transaction_type=create_payment_token
currency=usd
amount=100.00
locale=en
access_key=e2b0c0d0e0f0g0h0i0j0k0l0m0n0o0p3
profile_id=0FFEAFFB-8171-4F34-A22D-1CD38A28A384
transaction_uuid=02815b4f08e56882751a043839b7b481
signed_date_time=2013-07-11T15:16:54Z
signed_field_names=comma separated list of signed fields
unsigned_field_names=comma separated list of unsigned fields
signature=WrXOhTzhBjYMZROwiCug2My3jiZHOqATimcz5EBA07M=
payment_method=card
card_type=001
card_number=4111111111111111
card_expiry_date=12-2022
card_cvn=005
bill_to_forename=Joe
bill_to_surname=Smith
bill_to_email=joesmith#example.com
bill_to_address_line1=1 My Apartment
bill_to_address_city=Mountain View
bill_to_address_postal_code=94043
bill_to_address_state=CA
bill_to_address_country=US
Is this a REST or SOAP API? How can this be tested in Postman? I tested to check if either works, and was unsuccessful. There is no information on what to include in the header either, so this is a bit puzzling.
Example POST test I am attempting:
POST https://testsecureacceptance.cybersource.com/silent/token/create
Content-Type:application/json
Accept:application/json
{
reference_number:123456789
transaction_type:create_payment_token
currency:usd
amount:100.00
locale:en
access_key:e2b0c0d0e0f0g0h0i0j0k0l0m0n0o0p3
profile_id:0FFEAFFB-8171-4F34-A22D-1CD38A28A384
transaction_uuid:02815b4f08e56882751a043839b7b481
signed_date_time:2019-03-07T06:16:54Z
signed_field_names:profile_id,access_key,transaction_uuid,signed_field_names,unsigned_field_names,signed_date_time,locale,transaction_type,reference_number,auth_trans_ref_no,amount,currency,card_type,card_number,card_expiry_date,card_cvn,payment_method,bill_to_forename,bill_to_surname,bill_to_email,bill_to_address_line1,bill_to_address_city,bill_to_address_postal_code,bill_to_address_state,bill_to_address_country
unsigned_field_names:
signature:WrXOhTzhBjYMZROwiCug2My3jiZHOqATimcz5EBA07M=
payment_method:card
card_type:001
card_number:4111111111111111
card_expiry_date:12-2022
card_cvn:005
bill_to_forename:Joe
bill_to_surname:Smith
bill_to_email:joesmith#example.com
bill_to_address_line1:1 My Apartment
bill_to_address_city:Mountain View
bill_to_address_postal_code:94043
bill_to_address_state:CA
bill_to_address_country:US
}
"Is this a REST or SOAP API?"
The URL, https://testsecureacceptance.cybersource.com/silent/token/create, is used for Secure Acceptance Checkout API. Secure Acceptance Checkout API is neither a SOAP API or a REST API. It is designed to be used as an HTML form POST from a customers browser.
If your goal is to use a REST API from the browser then you will want to use Secure Acceptance Flexible Token documented here.
If your goal is to use Secure Acceptance Checkout API the full documentation for that is here.
"How can this be tested in Postman?"
Since this is not meant to be a REST API call but an HTML form POST and HTML response you may have limited success with Postman. For example even if you get the request to work successfully the response will be an HTML document not JSON.
One problem I see is that you are using the example signature, and that will not work for you. Ensure that you follow the documentation on how to create your signature as well as set the signed and unsigned fields.
#J.J. - the error you encountered -- "This field is invalid or missing.Please contact Customer Support.: ots_profileid' ". Is telling you that you are missing (or have an invalid) profileID in your request payload. The system doesn't know what profile to use when processing this request.
We have Splunk deployed in https://splunkit.corp.company.com (url modified).
and able to access Splunk Web home page on https://splunkit.corp.company.com/en-US/app/launcher/home (url modified).
I am building a dashboard application which uses the JSON data provided by Splunk REST services.
I have gone through the link and rest end points as here.
From above links I got know
I need to make post request to services/auth/login with username and password. This returns session key which will be used in further API calls.
Have to make post request to services/search/jobs to create a search. This returns search id.
I need to check services/search/jobs/ for search complete.
If search complete Then I can retrieve results using services/search/jobs//results.
The problem here I facing is I don't know whats the base URL. I tried constructing https://splunkit.corp.company.com/en-US/services/auth/login and etc but not working.
Any help appreciated. Thanks
I had the same question earlier. Well here is an workaround to find out the REST API Base URL. I found this solution by accident in fact.
In the Firefox browser, open the Web Developer / Network tool, to inspect the URLs between your local computer and the Splunk server
Logon to the Splunk via Web Interface
We assume you had finished a search beforehand, so there should be an Job stored on the Server already. Then, we click the Activity / Jobs link at the right top location of the window
There will be a list of jobs listed. Choose any job, click the Job / Delete Job button, then the Job search result will be deleted.
In the Web Developer tool, inspect the URL when deleting the job
For me, I got an URL looks like:
https://the-company-splunk-server.com/en-US/splunkd/__raw/services/search/jobs/scheduler_search_RMD554b7a649e94cdf69_at_1526886000_58534?output_mode=json
The top secret is: the URL before /services/ is the REST API Base URL. In this case, the base URL is:
https://the-company-splunk-server.com/en-US/splunkd/__raw/services/
Test the Base URl
We can try this Base URL for login with CURL:
curl --insecure https://the-company-splunk-server.com/en-US/splunkd/__raw/services/auth/login -d username=your-user -d password=your-password
We got the following result:
<response>
<sessionKey>kq6gkXO_dFcJzJG2XpwZs1IwfhH8MkkYDaBsZrPxZh8</sessionKey>
</response>
So the test is succeed. We have proven the base URL works.
Good luck.
I am trying to integrate the OneNote API as part of a new application. Is it possible to use Google Chrome's POSTMAN REST Client to test the API? The OneNote API appears to be standard REST, so there should be no reason why not.
To login, I followed the documentation and did a GET request in POSTMAN to
https://login.live.com/oauth20_authorize.srf?client_id=myClientIdIsHere&scope=wl.signin&response_type=token&redirect_uri=dontKnowWhatToPutHere
Broken down, that is:
https://login.live.com/oauth20_authorize.srf
client_id=myClientIdIsHere
scope=wl.signin
response_type=token
redirect_uri=dontKnowWhatToPutHere
I tried the following based off advice from this blog: http://blogs.msdn.com/b/onenotedev/archive/2014/07/23/how-to-authenticate-with-microsoft-account-in-a-chrome-extension.aspx
https://login.live.com/oauth20_authorize.srf?client_id=myClientIdIsHere&scope=wl.signin&response_type=token&redirect_uri=https://login.live.com/oauth20_desktop.srf
When I do a GET request to this, I get HTML back, but it does not show up in the preview mode.
Am I on the right track?
The code that you are trying to execute is just the initial part of the oAuth login process.
As you have mentioned the below peice
redirect_uri=dontKnowWhatToPutHere
redirect_uri is the URL of your application. Once the authentication is success, the server will redirect the navigation to provided URL and you can proceed further from here. Just keep in mind that the URL given is as same as the one you have provided while creating the azure app. If they do not match, the server is going to simply throw an exception.
Please change the JSON to
https://login.live.com/oauth20_authorize.srf
client_id=myClientIdIsHere
scope=wl.signin
response_type=token
redirect_uri=http://localhost:8008/login
Replace http://localhost:8008/login with your application login route.
I am working with Drupal 8.0 alpha 11. I've been able to follow the Drupal guides for REST services:
POST for creating content entities (https://drupal.org/node/2098511) and the related guides, GET on content entities and GET on Views-generated lists
"GET"s work great, but I haven't been able to get any "POST" to work (I've posted the issue on the drupal.org site, too).
I've tested POST for both a basic page and my own content entity and neither works. I've tried a lot of variations, including removing "entity" from the url as per the recent changes in Drupal 8, but the POST still does not work. I'm using Postman in Chrome for testing and again, I can "GET" a basic page and my own content entity just fine, but with POST, I always get a return code of 200 "OK", never "201" (which is what I should receive according to the guide) and the nodes don't get created.
I've updated the rest.settings.yml for both the basic page and my content type, have established permissions for the user, am using basic auth, and have added Content Type application/hal+json and cross-origin details to the header info.
Any idea what's missing? Do I need to add coding in my create entity form to "receive" the posted data? Where do I do this/in which directories should the files go? Is this required for the default Basic Page content type, too?
Thanks for any help...I've spent weeks on this and can't figure out what I'm missing.
Thank you!
On Drupal 8 alpha 11 it will work but make sure I am assuming that you have enabled REST , HAL, HTTP basic authentication, Serialization module on your site.
You have enabled POST method for 'entity:node' with basic_auth authentication type and hal_json as format
Give enough permission to a admin so that it can create node via REST , To do so navigate to admin/people/permissions on your drupal installation.
now /entity/node is REST end point to create node I am using REST Client to demonstrate POST request
this is link to image that will make it more clear
https://dl.dropboxusercontent.com/u/100492838/POST_Node.png
now make a POST request with Content-Type = hal+json and also set basic_auth header.
change URL according to your site.
I don't make this very general question post lightly, but I've maxed out what I can figure out on my own.
I'm starting up the QA Test Automation at my new company (they don't automate anything currently) and they've elected to use SoapUI for this procedure.
The application they're developing is a REST application (I don't really have any idea what that means) so I'm trying to build a REST request and Test Suite to reach our internal test server (which gets me XML that I am not allowed to post here - but it does reach the server successfully!) and then try to do a Login/Logout test.
I'm asking for help with methodology, because I have no idea where to start. I;ve Googled and trolled their support forums and looked in every corner of YouTube. Everyone is doing something different enough that I can't relate or use it.
Does anybody out there use SoapUI and test functional login in a REST application? I can write HTML/CSS and I'm pretty Java savvy, so I can do technical stuff if I know what to look for and what to learn.
Feeling overwhelmed. This was not in my job description when I started.
You should start with REST, and after that with SoapUI.
It is hard to catch the essence of REST.
It is like the hybrid of SOAP and a simple HTML driven web application. By SOAP you describe your web service with a WSDL. By a web application you send back hypermedia, so you don't have to write a WSDL or any descriptor to your application. This is convention over configuration...
REST uses the same approach, so it sends back hypermedia as well, but it sends not HTML, because it is not machine processable. The hypermedia sent by a REST API is usually an XML or a JSON derivative, for example ATOM+XML, JSON-LD, etc... If your web service does not send back hyperlinks, then it is not a real REST service just a SOAP web service with some REST constraints. There is a big difference. By SOAP you have to know everything about the operation name and the parameters if you want to send a request. If something changes, then your SOAP client breaks immediately. By REST your automated client follows links, checks their link-relation, or the bound linked data and recognizes which link is what it was looking for. So the modification of the link's url is irrelevant in the client, because it follows the vocabulary of the application, for example: hydra is a project which tries to describe these application level semantics in a general way, and tries to bind it to open linked data.
So at first you have to check that you have a real REST API, which follows the HATEOAS principle, or just a REST like SOAP web service. This is very important if you want to write end to end tests against it. By testing REST, you have to follow the links in your tests returned by the web API. By testing REST like SOAP, you have to build the links yourself in your tests... How to build such a link? I am sure you got a description of your REST API, but a link looks usually something like this in a JSON format:
{
rel: "link-relations",
method: "METHOD",
href: "domain/api-root/version/resource-path?map-reduce",
data: {...},
title: "...",
...
}
Ofc. there is some difference by every hypermedia, so you have to check your XML hypermedia type, how it represents links... The link-relations and maybe other attributes bind your data to the semantics of your REST API. The METHOD is always a verb, usually: GET, POST, PUT, PATCH, DELETE, maybe OPTIONS, and so on... There are only a few REST verbs, each of them has a specific meaning. In the url: The domain is the domain name of your application, e.g. https://example.com. The api-root is the root of your REST API, usually /api. The version is the version number of the currently used API, usually /v1. Only non backward compatible vocabulary changes should affect this version number. The resource-path is the path of your resource, usually /users or /users/inf3rno, etc... By REST you have resources. Each of them has a unique resource-path, and as you can see, every word in that path is a noun. So resources are something you can modify or display with a verb. For example a GET /users/inf3rno should return a representation of my profile page, and a PATCH /users/inf3rno {nick: "Leslie"} will turn my nick name: inf3rno into Leslie. By REST every resource should have only a single resource-path, so this is always a unique identifier, therefore the previous example with PATCH was not so perfect if you want to have multiple users with the same nick... The map-reduce in the queryString of the url, and it contains the sorting, pagination and filtering settings of the resource you want to modify or display. For example you can retrieve some data of every user with a first name: "Leslie" with GET /users?filters="firstName: 'Leslie'"&page=3&count=25. There is a difference between the following url-s: /users?id="inf3rno" and /users/inf3rno. The first one points to a collection resource and filters the result by its representation, the second one points to a single item resource. So a GET should return a collection representation with a single item by the first one, and an item representation by the seconds one. By the resource modifying methods there is no difference between the 2 urls... So it is recommended to add only a unique identifier to the resource-path if you want to select an item resource from a collection. By reducing the collection representation in any other ways, you have to add the filters to the queryString. The data part contains the params from the input fields. The title is the title of the link, and so on... You can use url-templates of you want to put input params to the url as well...
By REST the client maintains the session, and it sends the credentials (username, password) with every request. This is because the REST service is like John Snow, it does not know anything about the session or the identity of the user. It has to authenticate every request. To do that it uses a credentials -> permissions cache. This is a good approach, because the service scales very well if it does not have to maintain the session, which is part of the application state (the state of the client)... The REST service maintains only the resource state, which is not dependent on the clients...
The response to your REST requests is usually a hypermedia which contains the links you can follow and the data you requested. By REST like SOAP web services you get only the data in a JSON or XML format. Every response should contain a proper status header. The most frequent status codes are:
200 - ok (by successful PUT, PATCH and GET)
201 - created (by successful POST)
202 - accepted (by async request with eventual consistency)
204 - no content (by successful DELETE)
206 - partial content (by pagination with range headers)
301 - moved permanently (by migration)
304 - not modified (by cache)
400 - bad request (by invalid input)
401 - unauthorized (if no password given, or wrong username or password)
403 - access denied (if your account does not have permission to perform the task)
404 - not found (by unknown resource)
409 - conflict (by concurrency issues or duplicated request or db constraint problems)
410 - gone (if the resource was present before, but it is already deleted)
415 - unsupported media type (if the client wants the response in an unknown media type)
500 - internal server error (if the request was okay, but something went wrong by processing it)
By any error you have to send a detailed error message with a custom error code, which is understandable for the users, not just the developers...
That's how a REST API looks like.
To test it with e2e tests you have to set fixtures send REST requests and check their response. So it is like any other test... The SoapUI is not necessarily the best tool to do that, I read many complaints about it... I personally never used it, but it is not so hard to write your custom testing system. You need a testing framework, which can compare expected and actual values. You need something to send HTTP requests, or simply mock out the HTTP framework of the REST API. You need something for the fixture. By integration tests you can mock out the business logic and the HTTP framework as well, so by those you just inject the mock dependencies and check the calls. By e2e tests you need a test data set, and compare it with the result XML in your case... If you want to e2e test your client, you can use selenium if it is HTML based, maybe with nightwatch.js. By testing a real REST API, you'll need an automated browser, like selenium for your REST API implementation, which can select and follow the proper links. If you are developing the REST API you would write a browser like that anyways if you want an example client for your 3rd party client developers.