I have imported an API from swagger-UI and able to create an api and product,But when I am trying to publish ,I am getting this error.
Cannot have multiple operations with the same operationId: clearCache
Cannot have multiple operations with the same operationId: getConfigurationJSON
any help would be appreciated.
As stated in the error message, each operationId must be unique across all operations. This is further explained in the following Swagger-API issue and specification:
https://github.com/swagger-api/swagger-editor/issues/1146
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#fixed-fields-5
operationId: Unique string used to identify the operation. The id MUST
be unique among all operations described in the API. Tools and
libraries MAY use the operationId to uniquely identify an operation,
therefore, it is recommended to follow common programming naming
conventions.
If you add the --skip-validation flag only one of the getByID
operations will be generated
https://github.com/swagger-api/swagger-editor/issues/1146#issuecomment-270006562
Related
I like to use the correct HTTP methods when I'm creating an API. And usually it's very straightforward. POST for creating entities, PUT for updating them, GET for retrieving etc.
But I have a use-case here where I will create an endpoint that updates the status of multiple objects given 1 identifier.
e.g.:
/api/v1/entity/update-status
But note that I mentioned multiple objects. The initial thought of my team would be to use map it as POST, but it won't actually be creating anything, plus if you were to call the same endpoint multiple times with the same identifier, nothing would change after the first time. Making it idempotent.
With this in mind, my idea was to create it as a PUT or even PATCH endpoint.
What do you smart people think?
I imagine PATCH would be the most correct way. Although if you use a PUT it would also not be incorrect.
The difference between the PUT and PATCH requests is reflected in the
way the server processes the enclosed entity to modify the resource
identified by the Request-URI. In a PUT request, the enclosed entity
is considered to be a modified version of the resource stored on the
origin server, and the client is requesting that the stored version be
replaced. With PATCH, however, the enclosed entity contains a set of
instructions describing how a resource currently residing on the
origin server should be modified to produce a new version. The PATCH
method affects the resource identified by the Request-URI, and it also
MAY have side effects on other resources; i.e., new resources may be
created, or existing ones modified, by the application of a PATCH.
Whilst it is a convention in REST APIs that POST is used to create a resource it doesn't necessarily have to be constrained to this purpose.
Referring back to the definition of POST in RFC 7231:
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. For example, POST is used for the following functions (among others):
Providing a block of data, such as the fields entered into an HTMl form, to a data-handling process
Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles;
*Creating a new resource that has yet to be identified by the origin server; and *
Appending data to a resource's existing representation(s).
Clearly creation is only one of those purposes and updating existing resources is also legitimate.
The PUT operation is not appropriate for your intended operation because again, per RFC, a PUT is supposed to replace the content of the target resource (URL). The same also applies to PATCH but, since it is intended for partial updates of the target resource you can target it to the URL of the collection.
So I think your viable options are:
POST /api/v1/entity/update-status
PATCH /api/v1/entity
Personally, I would choose to go with the PATCH as I find it semantically more pleasing but the POST is not wrong. Using PATCH doesn't gain you anything in terms of communicating an idempotency guarantee to a consumer. Per RFC 5789: "PATCH is neither safe nor idempotent" which is the same as POST.
I am in a middle of a discussion here. Imagine that you have I want to delete all records from a collection using REST to https://api.example.com/files.
Is DELETE https://api.example.com/files a valid call?
You can refer published guidance regarding REST.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
It appears to be a valid scenario.
Similar discussion here: Is an entity body allowed for an HTTP DELETE request?
Is DELETE https://api.example.com/files a valid call?
Semantically, DELETE /files is no different from DELETE /anythingElse; that's the promise of the uniform interface, that all resources understand the methods to mean the same thing.
In the case of DELETE, the semantics are currently defined by RFC 7231.
The DELETE method requests that the origin server remove the association between the target resource and its current functionality. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation on the URI mapping of the origin server rather than an expectation that the previously associated information be deleted.
If your server happens to delete a bunch of rows in its data store when handling this request? That's just a side effect - it's an implementation detail of no concern to anyone other than the server itself.
In general, it is assumed that the origin server will only allow DELETE on resources for which it has a prescribed mechanism for accomplishing the deletion.
Relatively few resources allow the DELETE method -- its primary use is for remote authoring environments, where the user has some direction regarding its effect.
I'm building an API to allow the client of the API to send notifications to remind a user to update an Order status. So far, there are two notifications:
when the user hasn't marked the order as received;
when the user hasn't marked the order as done.
I want to build this API to make it simple to extend to other notifications related to the order, but keep a simple URI for the clients of this API.
How can I define my resources in order to keep my API RESTFul?
I was thinking about having one of these structures:
Option 1:
POST: /api/ordernotification/receive/{id}
POST: /api/ordernotification/complete/{id}
Option 2 (omit the status from the resource and post it instead):
POST: /api/ordernotification/?id={id}&statusID={statusID}
EDIT
Option 2.1 (keeping an articulated URI, as suggested by #Jazimov):
POST: /api/ordernotification/{statusID}/{id}.
Which option is more appropriate? Is there any advantage that one option has over the other? Or are there any other option I haven't thought of?
I would go with something along these lines
POST /api/order/1234/notifications/not-received
POST /api/order/1234/notifications/not-completed
Which can later be accessed via
GET /api/order/1234/notifications/not-received
GET /api/order/1234/notifications/not-completed
Or
GET /api/order/1234/notification/8899
There's no real limitation on how semantically rich a URI can be, so you might as well take advantage of that and be explicit.
If I understand you correctly, you have two types of ordernotifications: those for notifying receive and those for notifying complete. If those are two separate data models then I think nesting them is a good idea (i.e. a table called ReceiveOrderNotification and CompleteOrderNotification). If that's the case then you may want to expose two different endpoints entirely, such as POST /api/receiveordernotification and POST /api/completeordernotification.
But I don't think that's the best you can do, given so many overlapping similarities there probably are between order notifications. Now, option 2 is more like a GET, since you're using query parameters, so with your first option let's collapse them into this:
POST: /api/ordernotification/
and then pass it some JSON data to create the notifications
{
"orderId": "orderId",
"userId": "userId",
"prompt": "not marked received/not marked done"
}
I also removed the /{id} because when you POST you create a brand new thing and the id has not been created yet, usually. Even if the client is creating an id and sending it to the API it is a good practice to leave it open so your API can handle creating a new, unique resource in its own way.
This is RESTful is because a POST creates a resource ordernotification with certain data points. Your first option made actions a resource in themselves but that's probably not represented in any data model in your backend. To be as RESTful as possible, your API endpoints should represent the database domains (tables, collections, etc). Then you let your controllers choose what service methods to use given the data sent in the request. Otherwise REST endpoints expose all the logic up front and get to be a long list of unmaintainable endpoints.
I think, to update status of already inserted records, your endpoint should be PUT instead of POST.
You can use
PUT: /api/ordernotification/:id/status/
with clients json data
{
"status": "your_status"
}
according to request data, endpoint should update the record.
I am a beginner in Load Runner V 11.50. I was scripting a login page and then logout under Action. I applied the correlation from Design Studio. But the problem is, a single ID value is applied to all requests having the ID as parameter. In reality, the ID value generated from 1 request is passed in other and from the later request another ID value is getting generated in passed in rest all requests. So the replay status is failed. I guess multiple correlation is required in this case. Anyone can suggest anything on this?
Thanks in advance.
What you are likely referring to is a state variable, which is generated on page A and passed back on page A+1. You will need to handle this with manual correlation.
Automation in correlation is not meant to replace manual correlation, only to improve the efficiency of the developer when the pattern is well known. In this case because of the constantly changing nature of when a value is populated and used you will need to address this manually.
As you are a beginner, this is an opportunity for your mentor to reground the material from your classroom training and work with you to reinforce your manual correlation processes and skills. If you are being asked to perform without a mentor then your management is setting you up to fail as a new person in this field.
Here is a podcast which should help you on the identification front for manual correlation.
http://www.perfbytes.com/dynamic-data-correlation
Please put web_reg_save_param before each request which is generating dynamic value in this case.
Example:
web_reg_save_param("param1")
A
web_reg_save_param("param2")
B --> Pass {param1} in B
web_reg_save_param("param3")
C --> Pass {param2} in C
and so on...
Also learn capturing various LB/RB,escape sequences,Arguments in correlation etc.
You can try using auto correlation function of load runner for now. But this will not work in all cases. Any how uou need to learn manual correlation methods.
This article will be helpful:http://www.guru99.com/correlation-in-loadrunner-ultimate-guide.html
First you need to practice manual correlation from Generation logs. later on after experience correlations can be done from Tree view.
I'm brand new to JIRA API programming.
I need to get a list of unresolved issues.
From the API, the function getIssuesFromFilterWithLimit() looks like a likely candidate. And I have also read on another SO thread that an issue is unresolved if the system Resolution field contains no value.
So, how would I construct the call, e.g (I'm fishing here) in pseudocode:
getIssuesFromFilterWithLimit(resolution=NULL)
Or is there a better way to do this?
According to the JIRA RPC documentation, getIssuesFromFilterWithLimit uses a predefined JIRA filter to retrieve issues. It will not work with a caller supplied query or search terms.
To use this method, you will need to define a filter in JIRA so it can be referenced in the getIssuesFromFilterWithLimit call.
An alternative would be to use getIssuesFromJQLSearch which works with a caller supplied JQL expression to retrieve issues. The JQL to return issues with now resolution would be resolved is EMPTY.