I have an endpoint which takes an X-Request-ID header. This is described as:
parameters:
- in: header
name: X-Request-ID
schema:
type: string
format: uuid
required: true
However, if I have ten endpoints that take this header, do I have to keep repeating this or is there anyway I can get some re-use?
Thanks
To add to Helen's comment, you can achieve some reuse by defining X-Request-ID as a Parameter Object in the Parameters Definitions Object, then reference it (by using a Reference Object) in the parameters field of each Path Item Object to denote that it's applicable to all operations under the path.
Related
I have two REST Services: GET and PATCH.
The GET Service has a JSON Response and from which I need to trasnfer a property named tripId.
Add that property value to the URL of the PATCH Request as a resouce, i.e.,
https://patchRequest.com/api/trips/{tripId}/
Can any one tell me how to do it in SOAP UI/ READY API.
I'm not able to do it.
Thanks
Create a customer property in the test case section ( or even in the project section )
Add a Property Transfer test step and export the value to the holder that you created
Finally, Call the value in your URI
I haven't been able to find a clear answer, hoping someone can help.
If we have, say, a blog with posts, and each post can have comments, and each comment a related user. Is it against convention, if I request the comment, to include both the user and the post in the relationships?
data: {
type: 'comments',
id: '1',
relationships: {
post: {...}, //should this be here?
user: {...},
}
attributes: {...},
},
included: {...}
As paulsm4 correctly stated: "it is up to you".
But I can give you some advice about that.
In such situations, you can give the caller of the API the choice of having such links or not via a querystring flag, like
?relationships=post,user
In this case, if you do not specify the relationship flag, you'll get the simple comment data or you can decide to give them all; in the second case, you can use relationships as a sort of filter.
In some APIs, I've seen also a more invasive approach: embed the related object directly in the returned JSON.
With the same technique as before:
?embed=post,user
This should produce an embedded JSON object in the current JSON reply including the original objects just as you were asking something like "GET /post/123" or "GET /user/456" separately. This can be handy in some situations.
Often this flag is named "expand" denoting same or similar behaviour.
For an example open this API documentation from Atlassian and search for "expand".
It does exist an old "standard" for your problem called HAL that speaks about linking and embedding in REST APIs.
Even the Wordpress API offers such features, give it a look in the official documentation.
An alternative to this is to rewrite the entire API in GraphQL leveraging the REST approach.
Q: Should JSON API entities include a relationship for its parent?
A: I assume that's entirely up to you!
If your JSON is defined by some third party, then you have to live with what they gave you. Please post details on how the JSON is specified.
Otherwise, if you're "inventing" the format yourself:
One possibility is to have a relationships: field with a link to the "parent".
Perhaps a better solution might to invent a "container" (perhaps a simple array!) to hold your "records".
If this were a database, I'd have a "posts" table, and a "comments" table. The "comments" table would have a "Post ID" column as a foreign key into the "posts" table.
'Hope that helps ... at least a bit...
JSON API specification does not make any requirements on the attributes and relationships being included in a resource object. The specification is just saying how they must be formatted if they are included. If I did not missed anything, specification does not even require that all resource objects of the same type must have same attributes and relationships.
But I would argue that there isn't any value in not including the relationships. JSON API specification does not require a relationship object to include resource linkage data. On the contrary it's only talking about resource linkage data in context of a compound document, in which it's used "to link together all of the included resource objects without having to GET any URLs via links."
It's totally valid and could be considered best practice to only provide related resource link if the related resources are not included in the payload. Constructing such a link would not put any workload on your server since it does not require to query the database. It also does not make any relevant difference in payload size.
An example of a payload using both techniques would look like this. It assumes that the request explicitly asked to include related user using include query param.
// GET https://examples.com/api/v1/comments/1?include=user
{
data: {
type: 'comments',
id: '1',
relationships: {
post: {
links: {
related: 'https://examples.com/api/v1/comments/1/post'
}
},
user: {
data: {
type: 'users',
id: '2'
},
links: {
related: 'https://examples.com/api/v1/comments/1/user'
}
},
}
},
included: [
{
type: 'users',
id: '2',
attributes: {
name: 'John Doe'
}
}
]
}
You may also want to include a relationship link, which "allows the client to directly manipulate the relationship." Update relationships chapter of spec gives a deep dive into what you could accomplish using relationship links.
This code works fine:
[RouteArea("Main", AreaPrefix = "Hello")]
[RoutePrefix("{orgCode}")]
public class ResponseController : BaseController {
[Route("Save/{formCode}/{responseId}")]
public ActionResult Save(string formCode, int responseId, string questionCode){}
}
and Url.Action("Save", "Response") produces, for example, /Hello/org123/Save/form/123
However, if the Route attribute is changed and another segment added:
[Route("Save/{formCode}/{responseId}/{questionCode}")]
then Url.Action("Save", "Response") produces an empty string.
Is there a limit to how many sections can be defined in the route?
Is there a limit to how many sections can be defined in the route?
No.
But MVC only can build URLs using route values that it knows about. This can be a combination of route values that are passed to the Url.Action() method and values that are in the current request (usually passed through the current URL).
When the framework tries to determine which route to use, it selects the first route that matches all of the route values (controller, action, and anything else) and matches all of the (optional) constraints.
The route will not match if all of the conditions below are true for any of the parameters:
Have no defaults
Are not marked UrlParameter.Optional (NOTE: Optional parameters may not have any non-optional parameters to the right of them)
Are not present in the current request
Are not explicitly passed as route values to Url.Action() (or other method that calls UrlHelper to generate a URL)
Have constraint rules that do not match
In short, a route only matches if all of the required parameters are provided and constraints are satisfied.
So, apparently there is no questionCode in the current context, and since it is required to build the URL, you get an empty string. Most likely you need to pass it explicitly.
Url.Action("Save", "Response", new { questionCode = "123" })
You should also be careful to always explicitly pass other parameters if there may be cases where they are not present in the URL.
I faced the problem with generating React components with api-platform-generate-crud.
Model has property that is object email.
I have serializer that make my email object a string.
API endpoint is serving string.
It works for GET & POST.
When I try to generate React components error message is
TypeError: Cannot read property '0' of undefined
Looking deeper into it, looks like that generator still see my email as object not a string.
Any idea how I can force API to 'see' email property as string not object ?
The data model you define is authoritative. Types in the Hydra documentation reflect the ones in PHP classes.
Here, the email property is of type object. If you set the related data as a string somewhere, you don't respect this contract anymore. The Hydra documentation is not in sync with the returned data.
You can change the type of the email property in the Hydra documentation by decorating the api_platform.hydra.normalizer.documentation service.
But I would recommend to keep the PHP classes' structure of your entities as close as possible of the structure exposed through the API.
Your classes should reflect the output of the API. You can use custom data providers to deal with more complex data structure (ex: ORM entities) before hydrating the structure to expose.
I am trying to get the Query String Parameters in the controller from the following URL using javax.servlet.http.HttpServletRequest object:
http://example.com:8080/OAuthClient/oauth-callback#access_token=something&expires_in=1209600&username=abcuser
It does not work because it is separated by # instead of ?
Hence it works if I change the request to http://example.com:8080/OAuthClient/oauth-callback?access_token=something&expires_in=1209600&username=abcuser
Is there a way to work around this problem? I have to make it work with # separated query parameters. which property will contain the data after oauth-callback?
Those aren't query parameters. They're the fragment of the URI - and that isn't sent to the server at all. It can only be used client-side.
From RFC 3986:
A fragment identifier component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI.
... and (emphasis mine)
Fragment identifiers have a special role in information retrieval
systems as the primary form of client-side indirect referencing,
allowing an author to specifically identify aspects of an existing
resource that are only indirectly provided by the resource owner. As
such, the fragment identifier is not used in the scheme-specific
processing of a URI; instead, the fragment identifier is separated
from the rest of the URI prior to a dereference, and thus the
identifying information within the fragment itself is dereferenced
solely by the user agent, regardless of the URI scheme.