I'm developing a REST API, and am looking for a simple graphic utility that will let me test the full set of REST verbs (GET, PUT, POST, and DELETE); GET is obviously not a problem, but I'd like something that can encapsulate the basic functionality of being able to specify a content body for PUT / POST, specify headers, etc. I'm sure someone's done this sort of thing before, but I can't seem to find any references to a simple graphical bit of HTML / Javascript that will allow me to specify an endpoint, headers, body, etc. and execute a REST request. Such a thing would be very useful in many environments. Does anyone know of such a tool that's available without any licensing issues?
Note: ideally, I'd like to find something that can be embedded in a web page, i.e. no browser add-ons.
Although you said that browser plugins are second choice for you, I am using Postman Chrome plugin happily and recommend it.
I know this is not something you can embed, but if you just want to test your REST service with the relevant HTTP verbs I would recommend using Fiddler.
I once had similar requirement (test-utility inlined inside online-documentation to provide sample calls). Also no luck and couldn't find anything.
In the end I did:
Provide link to browser-addon RESTClient
Building little REST spefic HTML form (radio-buttons for verbs, URL field + payload). Backend was a simple controller respectively which was then forwarding the parameters to the real api. Very important was syntax highligthing for payload (XML, JSON) for me. For that I used nice JS-library code-mirror. Further more I had more control on the form (e.g. hiding/showing certain HTTP verb after entering URL). Overall building simple form as Rest Client was much less effort than I thought, which again shows that a good Restful API over HTTP makes clients very easy to develop.
Try Okapi: two files you can just drop into your webserver. It's free and free.
WizTools.org RESTClient
RESTClient is an excellent open source Java application you may want to try that can be used to test a variety of HTTP communications (it supports GET, POST, PUT, DELETE, HEAD, OPTIONS, and TRACE). It features a GUI version and a CLI version to suit either manual or automated testing. Note that it also provides SSL and scripting support.
Though it can't be embedded in a web page (as per your request), being a Java application, it can easily be run on numerous plaforms. As it is my own REST API testing tool of choice, I can highly recommend it.
Screenshot:
I've included this last as your "ideal" said no browser add-ons, however ... I've tried numerous REST clients and by far the best I've used is the Chrome app: DHC.
DHC (aka Dev HTTP Client) is designed and developed by a developer for developers to make direct HTTP resource discovery, manipulation and testing more easily. Beside the main function, sending/receiving custom HTTP requests/responses, it allows permanently to save a request to a local repository for later reuse and moreover the request declaration can include variables that are context specific. With the use of contexts you can easily switch between various environments without modifying request declaration. (e.g. from a test environment to production)
If you can get past the browser add-on aspect, I would strongly recommend giving DHC a shot.
Related
I am using Server side GTM, but I am facing adblocking issues when calling the below request when I want to retrieve the gtm?js file:
https://example.gtmdomain.com/gtm.js?id=GTM-MY_GTM_ID
The request works fine when I don't use adblockers.
Is there a way to rename the endpoint to something else, such as https://example.gtmdomain.com/secret_file_name.js?id=GTM-MY_GTM_ID in order to not be blocked by adblockers?
So. Server-side gtm is exactly what it says. It's executed on the server. It listens for network requests. It doesn't have any exposure to what happens on the front-end. And the front-end has no clue about there being a server-side GTM. Well, unless there are explicit calls to its endpoint, which you can proxy with your backend mirrors when needed.
What you experience is adblockers blocking your front-end GTM container. Even though it's theoretically possible to track all you need, including front-end events with server-side GTM, it's considered to be the best practice to use both GTMs and stream front-end events to back-end GTM through front-end GTM.
This, of course, makes you dependant on adblockers since they will block your front-end GTM. A way to avoid it is... Well, not to use the front-end GTM and have all your tracking implemented either in a tag manager that is not blocked (I doubt there is one) or just have your own custom javascript library doing all the front-end tracking and sending it to the backend GTM to be properly processed and distributed.
Generally, it's too expensive to implement tracking with no TMS, since now you really have to know your JS, so only the cool kids can afford to do this. A good example would be Amazon.
Basically, it would cost about two to five times more (depending on particulars) to implement tracking with no TMS, but adblockers typically cut only about 10% of traffic. 10% is not vital for reporting, measuring effectiveness of funnels and what not. All the critically important data is not being reported on by analytics anyway. Backend is the real source of critical data.
You can easily do this if you use sGTM hosting from https://stape.io
There is a feature called Custom Loader. With it, you can download Web GTM from different paths and all other related scripts will be also downloaded from different URLs, for example, gtag.js for GA4.
More info https://stape.io/blog/avoiding-google-tag-manager-blocking-by-adblockers
You can also create your custom loader client for Web GTM. However, there will be problems with related scripts. UA/GA4 still will be blocked then, but GTM itself not.
So, I finally implemented a great solution using GTM client templates. It works like a charm.
To summarize, the steps are:
Create a client template from your server container. You can import this template from https://raw.githubusercontent.com/gtm-templates-simo-ahava/gtm-loader/main/template.tpl
Create a new client from this client template
name your path as you want
This article explains perfectly the required steps: https://www.simoahava.com/analytics/custom-gtm-loader-server-side-tagging/
I'm about to create a JavaScript-based client for a RESTful webservice. The client should facilitate access to the webservice and wrap some raw HTTP calls into more "candy" functions and objects.
I'm intending to use this client library for node.js-based applications as well as for PhoneGap. So, I don't have to care about the Same-origin-policy. However, dispatching HTTP requests is totally differnt in PhoneGap and node.js.
Now I'm wondering how I can implement a client library in JavaScript, that is portable between different "platforms" (node.js, PhoneGap, perhaps later even browers)?
Thanks in advance
You might try this emulation of XmlHttpRequest under nodejs but you still may need to special-case your client library to operate under PhoneGap (and other browser-based JavaScript platorms) and nodejs.
One way to do this would be to check the contents of 'window' which is undefined by default under nodejs, or 'global' which is (should be) undefined in a browser.
EDIT
It appears I spoke(wrote) too soon. Check out abstract-http-request which while not explicitly supporting PhoneGap, might give you enough to work with.
Phonegap is basically just a browser. So if you want to get around the same origin policy you might want to take a look into different phonegap plugins (GapSocket) to handle your own communication.
REST is an architectural style for designing web services. A web service doesn't have to use HTTP to be RESTful, though a large proportion of them do. To be RESTful, an HTTP-based web service has to rigorously leverage HTTP's resource names (URIs), operations (GET, PUT, DELETE, etc), error codes (404, 200, ...), and so on. This means that any (HTTP-based) REST client framework can interoperate with any (HTTP-based) REST server framework: if it doesn't, something's probably wrong. So your problem decomposes into finding a good generic REST client framework and one or more generic REST server frameworks.
For node.js based web services, take a look at the Geddy server-side framework (here's the documentation).
For a PhoneGap REST client, you could try the Force.com JavaScript REST Toolkit (and see this extension).
Disclaimer: I have only read about these frameworks, not used them.
I had a discussion with my colleague about Flash security. We're in the phase of planning some things for our web project that is using Flash plugin to display content. We need to dynamically pull settings for the Flash application from the server, using JSON.
Proposal that I offered was that we should save an extra HTTP request to pull the data file after the plugin is loaded and embed the JSON directly in the page containing the Flash plugin. Flash would fire a Javascript function that'd return the deserialized JSON data to it.
My colleague opposed this proposal with significant "security concerns".
I believe that there's literally zero difference between these two approaches besides the fact that his approach requires additional HTTP request. All of this is client/server and client should never be trusted. If I want to change the data that is in the JSON query, I can do that in both cases. File pull is little more difficult to hack though, but possible with custom HTTP proxy.
What are your thoughts?
There is no difference. Both can be fabricated.
if you really care that much about delivering original settings to the .swf:
don't use http - httpFox is a brilliant plugin - use a server that supports RTMP/RTMPE and NetConnection.call() to retrieve the data.
create an algorithm for validating original json so that your app won't work if the config doesn't pass the test.
after the config is loaded your swf might check the values with the server (not all at a time) and throw an error if something goes wrong
Does anybody know of a way of checking on the API side if a XMLHttpRequest has been made from my own web-application (ie. from the JS I have written) or from a third-party application...
The problem, to me, seems to be that because the JS is run on the client and thus accessible to anyone I have no way of secretly communicating to the API server who I am. I think this is useful because otherwise I cannot prioritize requests from my own application over third-party clients in case of high usage.
I could obviously send some non-documented parameters but these can be spoofed.
Anybody with some ideas?
I would have your web server application generate a token that it would pass to your clients either in JavaScript or a hidden field which they in turn would use to call your API. Those with valid tokens get priority, missing or invalid tokes wouldn't. The web server application can create & register the token in your system in a way that limits its usefulness to others trying to reuse it (e.g., time limited).
If you do approve of third party clients accessing your API, perhaps you could provide them with a slightly different, rate-limited interface and document it well (so that it would be easier to use and thus actually be used by third-party clients).
One way to do this would be to have two different API URLs, for example:
/api?client=ThirdPartyAppName&... for third-party apps (you would encourage use of this URL)
/api?token=<number generated from hidden fields from the HTML page using obfuscated code>&... for your own JS
Note that as you mention, it is not possible to put a complete stop to reverse engineering of your own code. Although it can take longer, even compiled, binary code written in such languages as C++ can be reverse engineered, and that threatens any approach relying on secrecy.
A couple of ideas come to mind. I understand that secrets never last, so I agree that's not a good option.
You could run another instance on a different unadvertised port
You could do it over SSL and use certs to identify the client
A simple but less secure way would be to use cookies
You could go by IP address, but that could be an administrative nightmare
DISCLAIMER: I've already looked at various approaches to solve my issue, so please read this before labeling this as a duplicate question
I have a javascript running on https://xyz.com which has to retrieve information from an application ABC running on the user's local machine say port 8080.
My constraints are that I cannot modify the HTTP headers emanating form the ABC nor do I want the user to install another application which will be a conduit to route my requests through to ABC.
Cross-Domain/Window Messaging Options
a) window.postMessage: Ruled out since I cannot have script running on the local machine
b) XDR Object (IE) or Access-Control-Allow-Origin (Firefox,Safari et al): Ruled out since I cannot modify the header
c) JSONP: Again this will not work since I am unable to enclose the response within the function name
As a workaround, only meant for testing I've added the http://xyz.com to the trusted list and have enabled Access Data Across Domains for sites on this list. AFAIK, this option is only available on IE 5+ browsers. This workaround allows me to send and receive messages from http://127.0.0.1:8080
My question is two-fold
1) If I were to continue with the above approach when I go into production what are the security implications that I'm exposing the user to? Can I plug those holes?
2) Are there any other options that I can pursue to achieve my objective.
PS: I would like to be as far away from ActiveX or Flash as possible, but in case that is the only workable alternative to my current approach then I'll have to toe the line
Cheers
If the local application could serve a single html document, to act as a bridge, then you could easily use Cross-Document Messaging (for instance with easyXDM) together with ajax requests from this document to do this. This is a very simple approach and one commonly used.
easyXDM actually comes with such a document, you can read about it here.
I think that the easiest would be to put a server script on https://xyz.com which will act as a bridge between the javascript file and ABC. Then the javascript file will simply send an AJAX request to it's own server script which will take care of fetching the information from the remote domain. The only other viable solution which would work among most browsers and which doesn't require using some client technology like Flash or ActiveX is JSONP but you have ruled this out because you have no control over the remote domain.