I am trying to access a rest-api from Tosca. For now I am using the "Communicate: Rest over HTTP"-module as described in the manual and in the webinar.
The communication has the following sequence:
At the beginning, the client logs in to the server and receives a session-string in the data part of the packet.
The server then expects this session-string as a cookie in each request.
My problem now is to put this new cookie (for example "session=somerandomdata") into the CookieResource.
Unfortunately the manual only applies to already existing CookieRecources.
My question is now whether it is possible to build a CookieRecource with this new cookie.
Whenever a Set-Cookie-Header is returned from the server, a new cookie resource is created.
Please check the manual here: https://support.tricentis.com/community/manuals_detail.do?lang=en&version=10.0.0&url=tbox/wse_tc_session_cookies.htm --> a new cookie resource is created with the name "myCookieResource". This cookie resource can later on be used in the "send" part.
Does this answer your question?
Related
I have designed an API REST service (with Bonita) to which I can perfectly connect with Postman, with the following parameters:
By the way, the x-www-form-urlencoded option that is selected comes from the Content-type application/x-www-form-urlencoded header that is not displayed in my screenshot. The official Bonita specification states that this header is needed and I always get a 200-OK status code as an answer.
How can I specify an equivalent request with the body part in a Mendix Call REST service in a microflow? Here is what I have so far:
I guess the body part should be specified in the Request tab, but I just don't know how to do it properly. I always get the following error message for my connector, which means that, whatever I specify, the username is not taken into account:
An error has occurred while handling the request. [User 'Anonymous_69a378ed-bb56-4183-ae71-c9ead783db1f' with session id '5fefb6ad-XXXX-XXXX-XXXX-XXXXXXXXb34f' and roles 'Administrator']
I finally found that the proxy setting was the actual problem. It was set at the project scope and simply clicking on No proxy in the General tab did the trick! (both services are hosted on my local machine so far)
I just had to fill in the dedicated Authentication field in the HTTP Headers tab then, with the correct credentials, to eventually log in my Bonita service.
Situation:
Using recording with Jmeter I have generated a list of api requests. The way my test object works is that when you login using UI it creates a key for the entire session (which also keeps on changing), however there is an option of having a static api key for a user that you can use for all requests when sending the api requests NOT using the UI of my software.
Problem:
I have a list of api requests that I want to test but I would like to overwrite only one variable in the header of all my api requests (i.e. adding the static api key).
Is there a way of overwriting only one variable in all (most of) the headers?
The Header Manager lets you add or override HTTP request headers.
Create a header manager at the top and enter the common value. This value will be send with all the headers.
For more information check the below link:-
https://www.blazemeter.com/blog/using-jmeters-http-header-manager
Hope this helps.
Add/Copy desired HTTP Header Manager above the Thread Group OR above Recording Controller and remove/disable all HTTP Header Manager inside request samplers, all request samplers will use the Main HTTP Header by default.
Cheers!
I do not want my users to authenticate. But I do not anyone to steal my data. So my goal is to only serve the people who make a req from the front end of the app. How can I do this ?
Is there a built in function that I'm missing ? I know that there are session id generated, but not sure how to incorporate the session id to this situation.
Thanks
By using the term "front end" I would assume that you have a client requesting data in the form of JSON/XML or HTML templates. My first suggestion to get your answer is to be much more descriptive in your question. It is very hard to answer without knowing how your client is designed.
Assuming your client is written in html/js and run in a browser then I would suggest that you serve a static file (in the form of a .js file or a <script></script> tag inside an html file) that generates a token. You can pass this token back to your server for validation on every request for data. This means that only your app (front-end) can be the only thing that requests data from your api (back-end).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm trying to understand RESTful Web Services page 274 section HTTP PUT. Issuing PUT against a non-existent resource creates the resource. If PUT causes an existing resource to move, HTTP 301 (Moved Permanently) is returned with the new location. Requests to the old URI return HTTP 301, 404 or 410.
My question is about returning HTTP 301. This seems to imply that resources retain ownership of old URIs forever.
Consider: /companies/{companyName}/departments/{departmentName}
I see the following benefits of using HTTP 301:
Concurrency: If one user renames a company while another is in the process of navigating to a department, the latter will get HTTP 404 in spite of the fact that they did nothing wrong. HTTP 301 allows us to seamlessly redirect the second user to the new URI.
Bookmarks: Both humans and computers need to bookmark URIs for long-term storage. Humans post links in discussion forums. Computers use URIs for caching purposes and user preferences.
I see the following problems with HTTP 301:
Blocks long-term resource evolution: Over its life-time, department A is renamed to B, C and D. A few years later someone would like to create department A and is prevented from doing so by D. To be fair, I can't think of any practical example where this would happen so maybe it's a non-issue.
API versions limit its use: Even root resources change over time as new API versions are released and old versions are removed. What's the point of returning HTTP 301 if the client can't access the new resource the same way as it could the old?
What is the appropriate course of action? Should the URL hierarchy be modeled differently? Should the behavior/response be different?
If PUT causes an existing resource to move, HTTP 301 is returned with the new location.
Technically, you can't move resources in HTTP. If you are manipulating resources as a client, what you are doing is:
GET /oldurl
PUT /newurl
DELETE /oldurl
The server will not know that the new URL is a new location for the resource at the old URL, and there is no concept of URL persistence through redirection which can be established by the client using universal HTTP methods. If the service provides an API which allows you to move items, for example by passing certain parameters, and essentially doing the above behind the scenes but also creating a redirect in the process, then it is up to the service as to whether that redirect is overwritable with a new PUT operation or not, as well as what kind of redirect is to be used.
It's my understanding that when a post title gets renamed, we're supposed to keep track of the old name and return HTTP 301 when a client references the old address.
This has nothing to do with REST and is a manifestation of Cool URIs don't change. In a RESTful service, it is sufficient to link to the new URL via a resource or sequence of resources reachable from your service's entry point.
e.g. a HTML website is the normative example of a REST implementation
service entry point = /blog
/blog links to /blog/archive
/blog/archive links to /blog/new-post-title
since the blog service is designed to be consumed by humans using a web browser, it is expected that they may want to bookmark a URL to revisit it later. This is what redirects are for.
a machine-to-machine API has to do something similar:
service entry point = /
/ links to /companies with a rel of "http://myservice/rels/companies"
/companies links to /companies/new-company-name with a rel of "item"
No mention needs to be made of the old company name, because machines are not expected to bookmark a location, but instead to begin navigating from the entry point each time.
I would return a simple 404. This signifies that there is nothing matching the requested uri, and from the documentation, specifies:
No indication is given of whether the condition is temporary or permanent.
This way it is perfectly valid to created new resourced to replace those that existed sometime in the past.
Otherwise, if you're going to move a resource by renaming it, you could always return a 302, specifying the resource resides at a different location. You could return this status until a replacement is generated. The user must continue to use these headers to make sure the resource is still relocated:
Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests.
Answering my own question:
I can't think of any practical example where keeping HTTP 301 forever would cause problems.
Links are not meant to survive across API versions. Resources from one version should not reference resources from another version (even using HTTP 301). If a resource's URI changes as the result of an API change, the old API should keep on using the old URI forever.
UPDATE: According to Willy Tarreau idempotency only requires the application to redirect for a short period of time. Once the client has finished retrying a request, the redirect is no longer needed (at least not for idempotency). You might want to keep redirects around for a longer period of time, to support features such as permalinks, but nothing in the specification forces you to.
We are trying to implement a REST API for an application we have now. We want to expose read/write capabilities for various resources using the REST API. How do we implement the "form" part of this? I get how to expose "read" of our data by creating RESTful URLs that essentially function as method calls and return the data:
GET /restapi/myobject?param=object-id-maybe
...and an XML document representing some data structure is returned. Fine.
But, normally, in a web application, an "edit" would involve two requests: one to load the current version of the resources and populate the form with that data, and one to post the modified data back.
But I don't get how you would do the same thing with HTTP methods that REST is sort of mapped to. It's a PUT, right? Can someone explain this?
(Additional consideration: The UI would be primarily done with AJAX)
--
Update: That definitely helps. But, I am still a bit confused about the server side? Obviously, I am not simply dealing with files here. On the server, the code that answers the requests should be filtering the request method to determine what to do with it? Is that the "switch" between reads and writes?
There are many different alternatives you can use. A good solution is provided at the microformats wiki and has also been referenced by the RESTful JSON crew. As close as you can get to a standard, really.
Operate on a Record
GET /people/1
return the first record
DELETE /people/1
destroy the first record
POST /people/1?_method=DELETE
alias for DELETE, to compensate for browser limitations
GET /people/1/edit
return a form to edit the first record
PUT /people/1
submit fields for updating the first record
POST /people/1?_method=PUT
alias for PUT, to compensate for browser limitations
I think you need to separate data services from web UI. When providing data services, a RESTful system is entirely appropriate, including the use of verbs that browsers can't support (like PUT and DELETE).
When describing a UI, I think most people confuse "RESTful" with "nice, predictable URLs". I wouldn't be all that worried about a purely RESTful URL syntax when you're describing web UI.
If you're submitting the data via plain HTML, you're restricted to doing a POST based form. The URI that the POST request is sent to should not be the URI for the resource being modified. You should either POST to a collection resource that ADDs a newly created resource each time (with the URI for the new resource in the Location header and a 202 status code) or POST to an updater resource that updates a resource with a supplied URI in the request's content (or custom header).
If you're using an XmlHttpRequest object, you can set the method to PUT and submit the data to the resource's URI. This can also work with empty forms if the server supplies a valid URI for the yet-nonexistent resource. The first PUT would create the resource (returning 202). Subsequent PUTs will either do nothing if it's the same data or modify the existing resource (in either case a 200 is returned unless an error occurs).
The load should just be a normal GET request, and the saving of new data should be a POST to the URL which currently has the data...
For example, load the current data from http://www.example.com/record/matt-s-example and then, change the data, and POST back to the same URL with the new data.
A PUT request could be used when creating a new record (i.e. PUT the data at a URL which doesn't currently exist), but in practice just POSTing is probably a better approach to get started with.