POST params are empty in Zend_Rest_Controller - api

I'm using Zend_Rest_Controller to implement a RESTful API.
The GET action works fine, for example when I make the /user/id/1 request the :id parameter is present when I use $request->getParams().
However, when I make a POST request to /user, the postAction() is called just fine but there is no POST data in $request->getParams() or $request->getPost(). $request->getRawBody() shows that they are getting to the server fine though.
Is there any reason why ZF might not be populating the request object with these params? How do I access them?

Double check the content type on the http headers of the request. Should be multipart/form-data.

Related

How to distinguish between GET and POST

I'm writing a simple api for training using express. Here's my testing code:
var express = require('express');
var app = express();
app.post("/api/:var_name", function(req, res) {
res.send(req.params.var_name);
});
is simply testing to see if POST is working. When I call http://localhost:3000/api/1 I get Cannot GET /api/1, so the server is obviously interpreting the POST request as GET, what do I need to do to call POST instead?
Anything you call in the address bar of your browser will be sent via get. This is due to the fact that post-messages (and almost all other methods) do have a body-part. But there is no way for your browser to send additional information inside the body of the http packet.
If you want to test your routes for any method other than GET I would suggest you download a tool like postman.
https://www.getpostman.com/
BEWARE: This is my preference. You can of curse also use text based browsers like curl to test it.
The server interprets the request according to the verb you set in the HTTP request. If no method/verb is specified it is interpreted as GET(not sure about this part).
When you call that URL, you need to use the method as well. For example if you use the fetch API, you can call it like:
fetch(url, {method:"POST"})
If you're entering it in your browser and expect it to be interpreted as a post request, it's not. All browser url requests are GET. Use a tool like Postman to call different HTTP verbs. It's really useful when creating such APIs.
You can check out this answer on details of how to add body and headers to a post request: Fetch: POST json data

How to use a Postman Mock Server

I have followed the guide here to create a postman mock for a postman collection. The mock seem to be successfully created, but I have no idea how to use the mock service.
I've been given a url for the mock, but how do I specify one of my requests? If I issue a GET request to https://{{mockid}}.mock.pstmn.io I get the following response:
{
"error": {
"name": "mockRequestNotFoundError",
"message": "We were unable to find any matching requests for the mock path (i.e. undefined) in your collection."
}
}
According to the same guide mentioned above the following url to "run the mock" https://{{mockId}}.mock.pstmn.io/{{mockPath}} but what exactly is mockPath?
Within my collection I have plenty of folders, and inside one of these folders I have a request with an example response. How do I access this example response through the mock? Thanks for all help in advance!
Here's the Postman Pro API, which doesnt mention a lot more than just creating reading mocks.
I had the same issue seeing an irrelevant error but finally I found the solution. Unfortunately I cannot find a reference in Postman website. But here is my solution:
When you create a Mock server you define your first request (like GET api/v1/about). So the Mock server will be created but even when you obtain your API key and put it in the header of request (as x-api-key) it still returns an error. It doesn't make sense but it turned out that defining the request is not enough. For me it only started returning a response when I added an Example for the request.
So I suggest for each request that you create, also create at least one example. The request you send will be matched with the examples you have created and the matched response will be returned. You can define body, headers and the HTTP status code of the example response..
I have no Pro Postman subscription and it worked for me using my free subscription.
Menu for adding an example or selecting one of them for editing:
UI for defining the example (See body, headers and status) :
How to go back to the request page:
Here is the correct reply I get based on my example:
If you request in the example is a GET on api.domain.com/api/foo then the mockPath is /api/foo and your mock endpoint is a GET call to https://{{mockid}}.mock.pstmn.io/api/foo.
The HTTP request methods and the the pathname as shown in the image below constitute a mock.
For ease of use the mock server is designed to be used on top of collections. The request in the examples is used as is along with response attached to it. The name of the folder or collection is not a part of the pathname and is not factored in anywhere when using a mock. Mocking a collection means mocking all the examples in within your collection. An example is a tuple of request and response.
An optional response status code if specified lets you fetch the appropriate response for the same path. This can be specified with the x-mock-response-code header. So passing x-mock-response-code as 404 will return the example that matches the pathname and has a response with status code of 404.
Currently if there are examples with the same path but different domains, and mock is unable to distinguish between them it will deterministically return the first one.
Also if you have several examples for the same query :
Mock request accept another optional header, x-mock-response-code, which specifies which integer response code your returned response should match. For example, 500 will return only a 500 response. If this header is not provided, the closest match of any response code will be returned.
Optional headers like x-mock-response-name or x-mock-response-id allow you to further specify the exact response you want by the name or by the uid of the saved example respectively.
Here's the documentation for more details.
{{mockPath}} is simply the path for your request. You should start by adding an example for any of your requests.
Example:
Request: https://www.google.com/path/to/my/api
After adding your mock server, you can access your examples at:
https://{{mockId}}.mock.pstmn.io/path/to/my/api

Sending GET request parameters in body

I have an API which accepts many parameters.
Passing the values of the parameters will exceed the length of the URL Header.
I am using Postman client to pass the parameters in the body but this is not working any ideas on how to make this work.
The API accepts many parameters because the backend is legacy and is exposed as an API by a service bus.
Older versions of Postman didn't allow you to send body data with get request.
Yet, if your server receives data as URL parameters you won't be able just to change the way of sending them and include them to the body (server won't accept them).
So if the length of parameters is indeed so big and the server indeed can receive the same data from body instead of from parameters then the Postman is just not the tool that you can use (maybe cURL is for you).
If your server allows to send data only as URL parameters and they are so long (more then 2000 chars What is the maximum length of a URL in different browsers?) then I think you have no chances to test this API.
UPDATE: new Version 7.20.1 now allows to send Body with GET request
Workaround:
Change the request type to POST.
Set the value of your body
Change request type to GET
Send request and the body is included
Postman is already added this feature of sending body in get
request.
But i still i recommended to go for post request (if body is present) since many projects like angular http client does't have updated protocols yet.
Latest Postman supports body object for Get request
just choose json format as shown in pic above
If you want to make a GET request in Postman then you can use Params or Body to pass parameters, but not both. Either Params only or Body only. If you specify both Params and Body, Postman will select and send only Params (in GET request of course). So if you want it to send Body, clear Params.

AWS API Gateway with Python-EVE "where" not working in deployed API

I have a Python-eve public API, and we can query it in the way:
https://my-api.com/collections?where={"name":"peter"}
I want to create an API Gateway to proxy the same URL endpoint, in the way:
https://my-api-amazon-gateway.com/prod/collections?where={"name":"peter"}
What I did:
I create a new API Gateway, with a new resource "collections", and a "GET" method for this resource.
In the collections - GET - Method Execution, in Method Request:
in URL Query String Parameters, I add one with name "where"
in HTTP Request Headers, I add one with name "Content-Type"
In the "collections - GET - Method Execution", in "Integration Request"
in URL Query String Parameters I have name "where" and Mapped from "method.request.querystring.where"
in HTTP Headers, I add one item "Content-Type" with Mapped from "method.request.header.Content-Type"
If I go to Method Test, and I put {"name":"peter"} as where Query Strings, and application/json as Header content-type, all works very nice.
If I deploy the API and try same endpoint in the deployed API, it is not working:
https://my-api-amazon-gateway.com/prod/collections?where={"name":"peter"}
It returns an error 400 Bad Request. Nothing is logged in CloudWatch.
If I try to hit
https://my-api-amazon-gateway.com/prod/collections?where=test
Then all work as It should, I get HTTP 200 OK, with the Python-eve error The browser (or proxy) sent a request that this server could not understand.
that is the same result than If I try to hit
https://my-api.com/collections?where=test
So, for a reason that I do not know, the test works, but the deployed API Gateway it is not working when the query string is an object.
Any clue about this?
Thank you very much!
You will need to URL encode the parameter. The reason it works when testing via Method Test is because it takes care of encoding the parameters.
Instead of,
https://my-api-amazon-gateway.com/prod/collections?where={"name":"peter"}
Try it with,
https://my-api-amazon-gateway.com/prod/collections?where=%7B%22name%22%3A%22peter%22%7D
Hope this helps

REST api request method input parameters

i've been researching/creating a REST api, in the backbone.js to php context.
i understand the concept of HTTP verbs and when they should be used
GET - select
POST - create
PUT - update
DELETE - delete
i also understand the concept of passing an identifier as a semantic url, e.g.
GET http://api/users/123
DELETE http://api/users/123
in these cases the "123" is the id the business logic will use to get/delete a user.
but what about the POST and PUT contexts? when sending a request to
PUT http://api/users/123
the api will update user id 123 with the supplied parameters, here's where my question arises.
i would assume the input parameters to update with would be sent as PUT parameters. in php syntax this is represented as: file_get_contents('php://input') (this is the same for delete requests.)
when testing this via backbone.js it works perfectly.
but when i try and create a new element with
POST http://api/users/
i would assume the input values would sent as POST parameters/ in php syntax this is represented as $_POST. but this does not work.
after some testing, and reading up on rails style REST apis (which is what the backbone docs suggest), i realized that all request variables are sent the same way. if i change my code to use file_get_contents('php://input') to get the request parameters for every request type, backbone works perfectly.
is this standard fair for REST apis? or just "rails flavored" ones?
PUT, POST, PATCH, etc (everything but GET and DELETE*) accept request bodies. Generally data is passed as either:
A URL encoded string of name/value pairs (exactly the same as a URL querystring) that is decoded and parsed by the server into $_POST (or similar depending on your web framework of choice). This typically relies on the presence of a Content-Type header set to application/x-www-form-urlencoded (browsers do this by default when forms are submitted). If you see the data in file_get_contents('php://input') but not $_POST it's very likely this header is not present or is set to another value. If you're using Chrome, you can see what headers and body the client is sending in the Network tab of the dev tools.
The other popular request body format is to use Content-Type: application/json and then write out a JSON string to the body. This can be accessed via file_get_contents('php://input') and then parsed with a JSON parser.
* Note on DELETE: it's a little unclear whether or not using a request body with DELETE is allowed or a good practice.