I have an API where we want to save commercial breaks. There are also validations in terms of rules such as hour limit not breach, average duration with in limits etc.
Should such validations have a different endpoint such as POST commercialbreaks/validation and then we validate the same from UI
a. UI ->commercialbreaks/validation , if pass then UI hit commercialbreaks->POST /commercialbreaks.
b. or should we have a single endpoint i.e POST /commercialbreaks and then have /commercialbreaks/validation be called from inside inside this API.
Validation takes user input too for rules to validate against. We will have to pass the same whenever we hit POST /commercialbreaks if we go for b).
THere is a also a possibility that post validation there is a delay in save and then by then some changes have happened in system so we may need revalidation again.
Which is a better design approach. Also, we have a situation where Validation gives a message that it failed/passed and if user has the Override prvilige then he will be be able to override the validation and still be able to save the breaks. In this case should we have use the same endpoint POST /commercialbreaks with override flag =true/false. Please suggest.
You don't do validation on a second endpoint, because you ALWAYS want the validation to run. You should do client-side validation in case you want to visualize problems before the user hits the save button. Then it should be server-side validation happening on that one endpoint. If validation fails, please note that you can return http status 400, but also return a JSON object if necessary with all infos about any remedy suggestions. I guess, validation is an implementation design topic and not an API design one.
Related
TL;DR How to mix REST requests with some non-REST requests in SPA(frontend/backend)? Or might be I just get REST wrong?
We are planning new API for SPA and mobiles(plus probably some 3rd parties). There will be some requests which, I suppose, can't be covered by REST.
I am speaking mostly about requests which would make backend do something, which would modify state of document or give some additional info, based on document, but request itself is rather simplistic.
Here is really easy example. I want to add a comment to blog post. For example I might do it like this:
Create comment. POST /comment
Create connection between author and comment. POST /comment_author or PUT /comment with author_id.
Create connection between comment and post. POST /comment_post or PUT /comment with post_id.
I also could do something like POST /comment with {author_id, post_id} which actually seems most logical here.
Everything did work, comment added to blogpost and associated with author.
Now customer wants to get statistics for his comment, like words stats and letters stats. As a part of request I pass comment_id. Backend might update comment with stats data, it might create separate entity and link it with comment or it might just send me those stats for this comment without saving.
So what would be the choices?
I can do something like:
GET/PUT /comment/:id/stats. For me it seems already hack, because as a result I don't want a document of type comment, but document of different type. As well as I don't send stats with request, I calculate them on backend so using PUT seems wrong.
POST/GET /comment_stats/:comment_id. Seems legit, but if I don't have a document/entity of type comment_stats, that would mean that I actually ask backend to create something, backend would reply me OK/Created, but actually I don't have this document somewhere saved.
So, while I understand REST != CRUD, I thought to use REST for simple CRUD and, for cases like that, to use RPC. So in RPC scenario I would just call POST comment.stats(comment_id)
My questions are what would be better choice in this situation, as well as are my thoughts about rest/rpc right?
I would go with GET /comment_stats/:comment_id for proper separation of concerns, so that report code doesn't clutter the comment resource.
It doesn't matter if you don't actually have a comment_stats document, or how the data is represented on your backend. The REST API is just an abstraction over your backend.
In general, for any non-CRUD action like this, it's better anyway to create a new resource and deal with it as if it was a "machine": you send some instructions to the machine (via a GET or POST call). The machine executes it and then returns the result. A simple example would be an endpoint to convert images: you create an /image_converter end point (the machine), you POST an image to it, it converts it, and sends back the image. /image_converter would have no associated entity/document in the database but for the end user it's still a resource with a logical behavior.
In a plain Play application I have the following scenario.
A route file which looks like this:
GET /accounts/add controllers.Accounts.add()
POST /accounts controllers.Accounts.create()
The first route results in a view where I can add a new account. The form to submit the new account looks something like this:
#helper.form(action = routes.Accounts.create()) {...}
Now the controller binds the input to the form and checks for any validation errors:
public static Result create() {
Form<Account> form = Form.form(Account.class).bindFromRequest();
if (form.hasErrors()) {
return badRequest(views.html.account.add.render(form));
}
...
}
Now the thing is, the client will see the same view with some additional error messages. However, meanwhile the URL has changed from http://example.com/accounts/add to http://example.com/accounts.
If the client now reloads the browser this calls GET http://example.com/accounts (which isn't even mapped in this scenario - thus getting a 404 - Not Found).
Maybe it's just me but I find this kind of annoying and browsing some GitHub projects I couldn't find a good solution for this case.
Of cause things would be much simpler if the second route is rewritten to:
POST /accounts/add controllers.Accounts.create()
... in which case everything works fine. But from a REST point of view this doesn't feel good either. The same applies to update scenarios (having GET /accounts/:id/update vs. PUT /accounts/:id).
Is there a guide on how to handle this? Am I getting something wrong or is this no problem at all (from a pragmatic point of view)?
It's not possible to leave the previous URL because a request for a new address has already been made. A controller only provides response for a requested resource. To go to the previous URL you could only make a redirect in case of validation failure but you would lost errors that way so this is not a solution.
I suggest mapping both actions with the same URL. This way you would solve problem with the browser reload.
If you create a REST service for http clients that aren't browsers you will probably want to serve different response than a simple http page. The separation of actions for particular clients could be a good solution for keeping REST API clean and a browser user happy.
I'm working on a CRUD application using Dancer. One of the things I need to do is check a user is authorized to perform POST (create) and PUT (update) / DELETE (remove) operations.
I've read up on before hooks in the Dancer documentation, but have been unable to figure out the best way to do varying types of authorization.
For a POST operation, all I want to do is check that a valid API key has been submitted with the request, but for a PUT/DELETE operation, I want to check that the API key submitted matches the user who is attached to the record to be updated or deleted.
I understand how to do the logic behind checking the API keys, but I'm wondering if hooks (or something else) would allow me to call that logic without having to add the same boilerplate function call to every single PUT/POST/DELETE function on every route.
like I told the poster on IRC, I think a combination of https://metacpan.org/pod/Dancer#request (the Dancer request object) and its HTTP verbs querying things should do the trick. See for example: https://metacpan.org/pod/Dancer::Request#is_post .
I'm not sure if it's a very elegant solution, but I think it should work.
Here's another take on this issue, based on experience:
Since Dancer has not had the opportunity to parse your input parameters when the 'before' hook executes, you may not have a consistent way to read in your authentication credentials, if your application allows them to be provided in a variety of ways.
In particular, if you're using input parameters to pass a nonce to prevent CSRF attacks (which you should definitely consider!), you won't have a consistent way to obtain that nonce. You could do your own mini-parameter-parsing within 'before', but that could be messy too.
I ran into this problem when I worked on an application some time ago, and remember having to add the dreaded boilerplate authentication function to every PUT/POST/DELETE route. Then, if you're doing that, it becomes irrelevant to check request->is_post because you're already deciding whether to place the boilerplate authentication function within the route.
I haven't tried this yet, but it may be possible to handle the pre-requisite action in your Route base class, then pass upon success. This will leave your specific packages to handle the request as normal once your base class has verified authentication.
An action can choose not to serve the current request and ask Dancer to process the request with the next matching route. This is done with the pass keyword, like in the following example
get '/say/:word' => sub {
return pass if (params->{word} =~ /^\d+$/);
"I say a word: ".params->{word};
};
get '/say/:number' => sub {
"I say a number: ".params->{number};
};
I am developing a webshop, where it would be nice if the customer's input is not lost during the checkout process.
I am making a form, and to make sure the data is kept after a refresh, I now send the input-value through post at the onchange event. I store this in a session-object that represents the form. I use this object to fill the form on page-load/refresh.
This does result in a lot of post-requests, one for each input filled instead of just one for the whole form. I can imagine this would impact performance. Is this something I should worry about, and if so, how can I perform the same type of thing without all the requests?
It depends, if you expect enormous count of customers:)
Instead of posting after every change, you can also store these data in cookies on client side and ignore posting at all before complete submit. Or not post after each change but rather after some meaningfull timeout when some changes has been performed...
I'm writing a Catalyst application that's required to have a fairly short session expiration (15 minutes). I'm using the standard Catalyst framework authentication modules, so the user data is stored in the session -- i.e., when your session expires, you get logged out.
Many of the uses of this application will require >15 minutes to complete, so users will frequently submit a form only to find their session state is gone and they're required to log back in.
If this happens I want to preserve the original form submission, and if they log in successfully, continue on and carry out the form submission just as if the session had not expired.
I've got the authentication stuff being handled by an auto() method in the controller -- if you request an action that requires authentication and you're not currently logged in, you get redirected to the login() method, which displays the login form and then processes it once it's submitted. It seems like it should be possible to store the request and any form parameters when the auto method redirects to the login(), and then pull them back out if the login() succeeds -- but I'm not entirely sure of the best way to grab or store this information in a generic/standard/reusable way. (I'm figuring on storing it in the session and then deleting it once it's pulled back out; if that seems like a bad idea, that's something else to address.)
Is there a standard "best practices" or cookbook way to do this?
(One wrinkle: these forms are being submitted via POST.)
I can't help thinking that there's a fundamental flaw in mandating a 15 minute timeout in an app that routinely requires >15 minutes between actions.
Be that as it may, I would look at over-riding the Catalyst::Plugin::Session->delete_session method so that any contents of $c->request->body_parameters are serialised and saved (presumably to the database) for later recovery. You would probably want some rudimentary check of the POST arguments to ensure they're what you're expecting.
Similarly, create_session needs to take responsibility for pulling this data back out of the database and making it available to the original form action.
It does seem like a messy situation, and I'm inclined to repeat my first sentence...
UPDATE:
Whether you use delete_session or auto, the paradoxical issue remains: you can't store this info in the session because the time-out event will destroy the session. You've got to store it somewhere more permanent so it survives the session re-initialization. Catalyst::Plugin::Session itself is using Storable, and you should be able to with something along these lines:
use Storable;
...
sub auto {
...
unless (...) { #ie don't do this if processing the login action
my $formitems = freeze $c->request->body_parameters;
my $freezer = $rs->update_or_create(
{user => $c->user, formitems => $formitems} );
# Don't quote me on the exact syntax, I don't use DBIx::Class
}
...
my $formitems = $c->request->body_parameters
|| thaw $rs->find({$user => $c->user})->formitems
|| {} ;
# use formitems instead of $c->request->body_parameters from here on in
The underlying table probably has (user CHAR(x), formitems TEXT) or similar. Perhaps a timestamp so that nothing too stale gets recovered. You might also want to store the action you were processing, to be sure the retrieved form items belong to the right form. You know the issues for your app better than me.
I would store the form data as some sort of per user data in the model.
Catalyst::Plugin::Session::PerUser is one way of doing that (albeit somewhat hackishly). I would reccomend using the session plugin only for authentication and storing all the state info in the model that stores your user data instead.
And I totally agree with RET's opinion that the 15 minute limit seems really counter productive in this context.
I came across this whilst searching CPAN for something entirely unrelated.
Catalyst::Plugin::Wizard purports to do exactly what you need. The documentation suggests it can redirect to a login page whilst retaining the state of the previous action.
NB: I haven't used it, so can't vouch for its effectiveness.
In the end, we ended up grabbing the pending request (URL+params) in the auto(), serializing and encrypting it, and passing it via a hidden form element on the login page. If we got a login request with the hidden element populated, we decrypted and deserialized it and then redirected appropriately (making sure to pass through the standard "can this user do this thing" code paths).
You could always have some javascript on the client that keeps the session from expiring by making a small request every few minutes.
Or you could have AJAX check for an active session before posting the form and presenting the user with a new login box at that time if needed.