I have an use case to convert the Arabic to English language using Informatica Developer tool.
I am calling Rest Web Service consumer (POST Method) to Azure translator services.
POST method Request to the service should be in the below format:
(Note: Array of text (denoted by [..]) should be passed to the service)
[
{"text": "Hi, How are you?"},
{"text": "The quick brown fox jumps over a lazy dog"}
]
I have provided the other parameters in the URL and Headers in the RequestInput of the Transformation.
Service will not be able to provide the output if the request is not in the desired JSON format ( Example mentioned above).
I am facing issue while I am configuring the Request body in the RWC tx. I have tried multiple options, but to no avail.
Times I end up constructing in the below formats, but this is not the desired request body format.
1.
{"text": [
"I would",
"really"
]}
{"row": [
{"text": "I would re"},
{"text": "I would re"}
]}
In above case (2nd), it has constructed well but due to additional parent tag {"row": , I am getting the error:
{"error":{"code":400074,"message":"The body of the request is not valid JSON."}}
Additional note: when creating the XSD schema, I can't avoid the parent tag row. Also, the parent tag should be having maxOccurs="unbounded" to be able to accept the array format.
Any suggestions, guidance would be highly appreciated :)
Thanks
Related
I think this is a classic and typical question but I didn't find its answer.
In my knowledge, the POST method is used to send data to the server with request parameter in message body to make it secure. And GET method is to retrieve data with parameters in the URL.
But what I didn't understand is how the same api may have different behavior by just changing the method.
Here is an example. I use SoapUI 5.5.0, this is the link of the api: https://reqres.in/api/users/1
when I use GET method I get this:
{
"data": {
"id": 1,
"email": "george.bluth#reqres.in",
"first_name": "George",
"last_name": "Bluth",
"avatar": "https://s3.amazonaws.com/uifaces/faces/twitter/calebogden/128.jpg"
}
}
and by changing only the method to POST, I get this:
{
"id": "244",
"createdAt": "2020-02-27T14:30:32.100Z"
}
(the id and date changes each time)
as described in this link https://reqres.in/ that it is creating an instance and we can add parameters..
BUT, can any one explain how is it technically possible to have different behavior with different methods on the same URL.
In my knowledge, the POST method is used to send data to the server with request parameter in message body to make it secure. And GET method is to retrieve data with parameters in the URL.
That's probably getting in your way.
HTTP Requests are messages; each message starts with a request-line
method SP request-target SP HTTP-version CRLF
The request-target identifies the target resource upon which to apply the request
The method token indicates the request method to be performed on the target resource.
You can think of it being like a function call
GET(target-resource)
POST(target-resource, message-body)
Or equivalently you can think of the resources as objects that share an understanding of message semantics
target-resource.GET()
target-resource.POST(message-body)
But what I didn't understand is how the same api may have different behavior by just changing the method.
The same way that an api can exhibit different behavior by just changing the request-target.
In HTTP, the request-line is literally human readable text that the server will parse. Having parsed the request-line, the server program can then branch to whatever code it wants to use to do the work, based on the values it found in the message.
In many frameworks (Spring, Rails) the branching logic is provided by the framework code; your bespoke handlers only need to be correctly registered and the framework ensures that each request is forwarded to the correct handler.
how is it technically possible to have different behavior with
different methods on the same URL
for the technical possibility, you can look at the spring framework's answer to this.
You can have a controller that is accessible on a single url but can contacted in four says, GET, PUT, POST, DELETE. To do this, Spring provides the annotations #GetMapping, #PostMapping, #PutMapping, #DeleteMapping.
All the requests are sent to the same url and Spring works out which method to call based on the verb.
In Restful APIs, verbs have very important meaning.
GET: Retrieve data
POST: Create a new entity with the request's body
PUT: Replace an entity with the request's body
PATCH: Update some properties of an entity with the request's body. A.K.A. Partial update
In your case, changing the verb from get to post has the effect of creating a new entity with ID 1. That's why you get a response with the newly created ID and a createdAt timestamp.
I have one question that i am finding hard to clearly identify the correct answer.
My API has one endpoint that does pagination. So, in the response i have to return to the client the total number of lines afected by the query. The count of records in practice.
I have read that, i should be passing metadata like what i want in the body, enveloping it, but i have also read that, it is not ok to afect the body with meta-data and that the future is to return only non meta-data on the body meaning that it must be on the response header.
O'reilly
If the information you are conveying through a custom HTTP header is important for the correct interpretation of the request or response, include that information in the body of the request or response or the URI used for the request. Avoid custom headers for such usages.
So, my question is, what is the correct approach to the problem? Should i pass the number of lines in response headers or put it in the message body.
Thank you very much.
For pagination, you could use an envelope in the response payload:
{
"data": [...],
"paging": {
"first": "http://api.example.com/foo?page=1&size=10",
"previous": "http://api.example.com/foo?page=2&size=10"
"next": "http://api.example.com/foo?page=4&size=10"
"last": "http://api.example.com/foo?page=5&size=10"
}
}
A similar approach is described in the RFC 5005: each page of results is a separate resource, which contains hyperlinks to the previous and next page of results
You also could use the Link header (line breaks are just for readability purposes):
Link: <http://api.example.com/foo?page=1&size=10>; rel="first",
<http://api.example.com/foo?page=2&size=10>; rel="previous",
<http://api.example.com/foo?page=4&size=10>; rel="next",
<http://api.example.com/foo?page=5&size=10>; rel="last"
Check the link relations registered in IANA.
For returning the number of records, I've seen some APIs using custom headers such as X-Total-Count, but I don't recommend such approach. Send those details in the response payload then.
I'm trying to POST into an API I have made, and I am testing it using Postman. I am getting back a 400 Bad Request error back as a response with the message Invalid JSON message received.
This is an example of the record being feedback to the user using GET.
{
"id":3,
"title":"Radio Etiquette Book",
"summary":"This book provides advice on how to present a radio programme with flair.",
"timestamp":"2016-12-22T18:18:20+0000",
"author":{"id":1,...***},
"reviews":
}
I presume the problem is with author because author contains sub fields, such as ID, username, password and sub classes called entries (books created by that author), and reviews (reviews written by that author).
How can I POST a new entry to avoid a 400 Bad Request error? I'm not sure which value it is, that I am posting incorrectly, but debating on whether it is actually author, and how it should be entered.
You can use a site like JSONLint to inspect whether or not the JSON you're trying to send is properly formatted. It should be able to show you the line of the error and why it might not match the JSON spec.
link to JSONLint
I am a newbie to the apigility code-connected service & was able to create a RESTful service with fetch and fetchall class method on the mapper file.
Can someone point me a good sample for insert (POST) data via REST service ?
Thank you,
Kevin
POST is going to be used for creating a new resource typically. This means that in your request you're going to want the following headers:
Accept: application/json
Content-Type: application/json
The first tells Apigility what sort of a response it is expecting. The second says that the data you'll be providing to the API will be in json format.
Apigility uses json or json+hal by default for a return and expects json for the incoming data.
When you're creating a new resource, typically you'll be persisting it in a database and as such the id of the resource will be generated by your code or database. The rest of the resource will be provided by the caller to the API. Example:
POST /api/user
{
"username": "kevin voyce",
"firstname": "kevin",
"lastname":" "voyce"
}
If you do this, you should see a response of something like
405 - Method Not Allowed
The body of the error should indicate that the method has not been defined. The error message is coming from the create method in the resource. Inside this method, you'll see an argument called $data which at this point will consist of a PHP stdClass with fields matching the stuff you passed in via the JSON body.
This is where the fields part of configuring your API in Apigility comes in. If you set up the names of the fields and put validators on the fields, Apigility will make sure that the fields that are passed in conform to and are valid according to these validators before the call is made into your API. The same applies to not just POST, but PATCH and PUT as well. This means that within your methods you don't have to worry that the input hasn't been validated (as long as you correctly configured your validators).
We have one existing API, which we're trying to build a Blueprint for, that requires certain request bodies to be URI-encoded JSON.
Is there some way to specify a body as "like this, but encoded"?
Existing (mere text) documentation just shows the JSON, along with an airy reminder to encode it before sending:
POST /blah/blah/blah
Content-Type: application/x-www-form-urlencoded
Parameters: (x-www-form-urlencoded)
{ "title": "Buy cheese and bread for breakfast." }
But with Blueprint—and especially with Blueprint at apiary.io—you really have to show the actual body. Which is completely unreadable:
### Create a Note [POST]
+ Request (application/x-www-form-urlencoded)
%7B%20%22title%22%3A%20%22Buy%20cheese%20and%20bread%20for%20breakfast.%22%20%7D
But specifying the readable text in the Blueprint fails (returns a parameter error):
### Create a Note [POST]
+ Request (application/x-www-form-urlencoded)
{ "title": "Buy cheese and bread for breakfast." }
The real sticking point is when I have Apiary talk to my real server: the readable request fails (because it's not encoded), while the unreadable one succeeds (because, as required, it is).
I believe this is something not yet support but which is being tracked here: https://github.com/apiaryio/api-blueprint/issues/25