The issue
Can I use actions2 for GET requests with query params?
Example
https://path/filename?id=123&age=45
If this is the url in request, can I access each param as input.id and input.age?
I have not found many resources (basically only one) that show examples of this syntax being used for requests with query string parameters.
The github page redirects to a blog where they talk about the different methods one can apply actions2 syntax to, but does not directly display an example with a GET request
https://www.logisticinfotech.com/2018/sails-js-actions2-example-with-crud/.
The only online source that somewhat confirms this affirmation is the following:
how to get query parameter in action2 in sails.
I am a newbie in SailsJS so feel free to ask me additional information.
Yes, you can use Actions2 for any API request; PUT, POST, GET, etc.
Here is an example from a repo I open sourced: https://github.com/neonexus/sails-react-bootstrap-webpack/blob/release/api/controllers/admin/get-me.js
While the example isn’t using GET params, it would use the “inputs” section just like with a PUT.
Related
I write an API for report fetching with detailed filters, such as filters for recordIds, userIds, tagIds, basically multiple different id lists are part of the filter.
So far I coded these fetches as POST requests with id lists in body but I got curious if it is possible to handle these filters as a GET request instead?
What I searched so far yielded that, it doesn't seem possible since there is multiple List based filters and request is likely too big to be a GET but still, I'm curious if there is possible work arounds?
In my opinion, this is according to your requirement.
If you are using post, you could post a complex object inside the body and this request will be more security than the get method.
If you wan to use get method, you could put all the parameter inside the url. Each url will contains the limit and build the complex object in the url is not recommended. If this also match your production environment, you could modify the codes to use get method.
I have used this blog post to attempt to setup an endpoint to retrieve generic inquiry data but I appear to be missing something. Our default endpoint is on Contract 1 so I did not extend that endpoint, is that necessary to get this to work? We have another custom endpoint and I setup the generic inquiry as laid out in the blog post but when I make the PUT request via postman with the "$expand=Result" parameter I receive a 500 and exception error "The given key was not present in the dictionary".
I am not super familiar with Acumatica or generic inquiries but from that blog post and other resources my understanding is that in order to retrieve the results of a generic inquiry it cannot be setup as a top-level resource or else you will only receive 1 record. I am trying to retrieve the entire list of records.
Any help will be greatly appreciated!
Here is a screenshot of the setup:
The error message you describe usually indicates something missing with respect to the endpoint. Per the blog post - did you define the endpoint like this (which is the correct structure)?:
If you are not sure, please post a picture of what you created in your custom endpoint, and I will see if I can assist from there.
I've actually been working on the same thing, referencing the same article.
I am able to get it to work as described. One question, are you specifying the $filter parameter? I only get this error when I try to use a filter. I am able to call the new endpoint and get back full results.
I found your post searching for a way to use a filter or I trying to find out if there is anyway to pass parameters to the GI from the rest call.
I am writing a REST API, which supports POST/GET/DELETE method for the same url.
For the DELETE method, the API needs extra parameters (details of the deletion). But the library I am using doesn't support request body for DELETE method, how can I do it?
If I put the parameter in URL like:
DELETE /API/Resource/id/parameter
Then I break the RESTyness.
Or I need to use another method POST/PUT, which is not RESTy, either.
Why is POST / PUT not RESTy? Take a look at the twitter REST API: You can destroy a status by POSTing to /statuses/id/destroy. That request does accept parameters. You could do something similar to this:
POST /API/Resource/id/destroy
I think that is RESTy enough.
Right now I have a REST service which creates a report via a POST:
POST http://myhost/reports
The report however is not persisted, and cannot later on be retrieved via a GET:
GET http://myhost/reports/{id}
Instead I return the report immediately in the response to the POST. Am I violating any REST principle here, e.g. anything a POST creates should always be accessible via a GET, or is this setup OK?
The POST method isn't a synonym to the create in CRUD. The POST method is used for any operation that isn't standardized, so as long as you document what it does, you're not violating REST, no matter what you do.
There's no such REST principle saying "anything a POST creates should always be accessible via a GET". This is a common misunderstanding due to conflating REST with CRUD. Read this answer for some clarification on that.
In informal language, what a POST says to the server is "take this data and apply it to the resource identified by the given URI, following the rules you documented for the resource media type."
No, you are not violating REST. As long as your interface is uniform it is up to you to determine what actions the urls of your API perform.
As part of your documentation you simply need to state which methods are valid for certain resources and which aren't. I really like to use the Twitter API as a good example of "What to do"
Example: Twitter REST API
POST statuses/update
does not create an object available for access at
GET statuses/update/3
The action performed by the POST method might not result in a resource
that can be identified by a URI. In this case, either 200 (OK) or 204
(No Content) is the appropriate response status, depending on whether
or not the response includes an entity that describes the result.
So according to the HTTP standard this is okay.
Given a one page app that uses push state and RESTful backend, we can imagine accessing the listing of a resource at /resourceName (i.e. /users). So /users would create a formated list of users
Now the problem is that this resource JSON or XML feed should also be mapped to /resourceName, so if boot form my application entry point at / then all is good, when navigating to /users the JS router can trigger a Ajax call that get the JSON data. Now the problem is if the URL is pointing directly at /users then i will land on a JSON feed instead of the actual listing. I could route all call to a main entry point and then let the JS router do the work though if i do so the AJAX call to fetch JSON wil brake.
I remember a while ago people adding .json to their json request, or even a GET parameter ?format=json and then having the controller taking different actions. I find that somewhat hacky.. Are there any other ways to go about this?
For that matter i am using laravel4 backend and backboneJS
I think the .json on the end of the request is the best approach. the other approach could be to create a separate endpoint endpoint for api request api.mydomain.com vs www.mydomain.com
What method you use to get a different response depends on how you'd like to go about it. Since you're asking about an opinionated topic (There is no one right answer), here's some options you can explore.
First, here's a good read from Apigee on API design, which covers what I'll write about here. See page 20 on "Support multiple formats"
The Rails way: Append a .json, .xml or other extension at the end of your request and handle that code within Laravel (You may want to use the "before" filter to check the request or Laravel's excellent route parameters, which allow the use of regex to define the route).
You can check the "accept" header in the request and set that header in your ajax calls to "application/json" instead of the default "application/html" to inform your application which format to use in its response. Again, the before or after filters may come in handy to check the request and define the response as appropriate
Create a query string `?format=json" or similar. Same comments as in point 1.
Laravel doesn't have built-in methods to change the response for you. You can, however, fairly easily detect what's being asked and choose which format to return in. It does take some thinking about how you want to accomplish that, however.
Some options off the top of my head:
Use the "before" or "after" filter to check what the request "wants" for a format, and do some transformations on the response to make that work
Extend the request and response class to "automate" this (request class to detect format, response class to transform the response to the correct format)
Hope that helps
It's valid to say which representation do you want. E.g. JSON, XML or binary, depends on what you want and which serializers have you developed.
You framework should support either setting of default representation or if you provide some mapping URL -> method you should be able to say which representation you are going to return - also either by default or taken within some object which represents your request.
I ended up using different endpoints as suggested by #Aaron Saunders. In laravel 4 this is dumb easy to implement using group routes:
app.php:
'domain' => 'whatever.dev',
routes.php:
define('APP_DOMAIN', 'app.' . Config::get('app.domain'));
define('API_DOMAIN', 'api.' . Config::get('app.domain'));
Route::group(array('domain' => API_DOMAIN), function()
{
// API ROUTES
});
Route::group(array('domain' => APP_DOMAIN), function()
{
// VIEW ROUTES
});
Beautiful!