In iPhone I have a register form composed of many UITextField. Now I have no validation on any of them and leave this to server to send me back errors messages.
The problem is how should I formatted error message from server. It used to be
{
email: ["email must be valid", "list of error message for this field"],
another_field: ["list of error message for this field"],
...
}
which is perfectly fine for showing error messages in html form, but not quite useful for iPhone.
My question is how should I formatted this errors message to be use for iPhone or should I replicate validation logic into my app for flexible customizable.
Server side or client side validation logic is up to you depending on your situation and there are pro's and cons of each. In general I would recommend client side validation for a few reasons:
API calls introduce problems of their own. What if it fails?
There is latency involved with the call. I don't want a user to type something or push a button and 2 seconds later something pops up to tell me my age is too young or something like that.
API calls use data that folks are paying for. Yes it's not a lot of data but every bit counts.
In general most of the validation logic I end up doing is fairly simple. Things more complicated like email can be tackled with regex.
That's just a few off the top of my head. Of course some things can't be done on the client such as checking for an available username. In this case you'll have to decide how much data from your error message you want to display to your user. In this case it looks like you have JSON and given that JSON can be recursive (dictionaries inside dictionaries or arrays inside arrays) you can write a recursive function to format it (if you want all of it of course). The other option is to have deterministic values in the JSON that you can query for and display to the user.
Related
I'm building a REST API and I'm trying to keep it as RESTful as possible, but some things are still not quite clear for me. I saw a lot of topic about similar question but all too centered about the "simple" problem of updating data, my issue is more about the business logic around that.
My main issue is with business logic triggered by partial update of a model. I see a lot of different opinion online about PATCH methods, creating new sub-ressources or adding action, but it often seems counter productive with the REST approach of keeping URI simple and structured.
I have some record that need to be proceeded ( refused, validated, partially validated ..etc ), each change trigger additional actions.
If it's refused, an email with the reason should be sent
if it's partially validated, the link to fulfill the missing data is sent
if it's validated some other ressources must be created.
There is a few other change that can be made to the status but this is enough for the example.
What would be a RESTful way to do that ?
My first idea would be to create actions :
POST /record/:id/refuse
POST /record/:id/validate ..etc
It seems RESTful to me but too complicated, and moreover, this approach means having multiple route performing essentially the same thing : Update one field in the record object
I also see the possibility of a PATCH method like :
PATCH /record/:id in which I check if the field to update is status, and the new value to know which action to perform.
But I feel it can start to be too complex when I will have the need to perform similar action for other property of the record.
My last option, and I think maybe the best but I'm not sure if it's RESTful, would be to use a sub-ressource status and to use PUT to update it :
PUT /record/:id/status, with a switch on the new value.
No matter what the previous value was, switching to accepted will always trigger the creation, switching to refused will always trigger the email ...etc
Are those way of achieving that RESTful and which one make more sense ? Is there other alternative I didn't think about ?
Thanks
What would be a RESTful way to do that ?
In HTTP, your "uniform interface" is that of a document store. Your Rest API is a facade, that takes messages with remote authoring semantics (PUT/POST/PATCH), and your implementation produces useful work as a side effect of its handling of those messages.
See Jim Webber 2011.
I have some record that need to be proceeded ( refused, validated, partially validated ..etc ), each change trigger additional actions.
So think about how we might do this on the web. We GET some resource, and what is returned is an html representation of the information of the record and a bunch of forms that describe actions we can do. So there's a refused form, and a validated form, and so on. The user chooses the correct form to use in the browser, fills in any supplementary information, and submits the form. The browser, using the HTML form processing rules, converts the form information into an HTTP request.
For unsafe operations, the form is configured to use POST, and the browsers therefore know that the form data should be part of the message-body of the request.
The target-uri of the request is just whatever was used as the form action -- which is to say, the representation of the form includes in it the information that describes where the form should be submitted.
As far as the browser and the user are concerned, the target-uri can be anything. So you could have separate resources to handle validate messages and refused messages and so on.
Caching is an important idea, both in REST and in HTTP; HTTP has specific rules baked into it for cache invalidation. Therefore, it is often the case that you will want to use a target-uri that identifies the document you want the client to reload if the command is successful.
So it might go something like this: we GET /record/123, and that gives us a bunch of information, and also some forms describing how we can change the record. So fill one out, submit it successfully, and now we expect the forms to be gone - or a new set of forms to be available. Therefore, it's the record document itself that we would expect to be reloading, and the target-uri of the forms should be /record/123.
(So the API implementation would be responsible for looking at the HTTP request, and figuring out the meaning of the message. They might all go to a single /record/:id POST handler, and that code looks through the message-body to figure out which internal function should do the work).
PUT/PATCH are the same sort of idea, except that instead of submitting forms, we send edited representations of the resource itself. We GET /record/123, change the status (for example, to Rejected), and then send a copy of our new representation of the record to the server for processing. It would therefore be the responsibility of the server to examine the differences between its representation of the resource and the new provided copy, and calculate from them any necessary side effects.
My last option, and I think maybe the best but I'm not sure if it's RESTful, would be to use a sub-resource status and to use PUT to update it
It's fine -- think of any web page you have ever seen where the source has a link to an image, or a link to java script. The result is two resources instead of one, with separate cache entries for each -- which is great, when you want fine grained control over the caching of the resources.
But there's a trade - you also need to fetch more resources. (Server-push mitigates some of this problem).
Making things easier on the server may make things harder on the client - you're really trying to find the design with the best balance.
While building my Web API, I have encountered some cases, where I'm not sure what HTTP verbs to use.
Downloading a file with a side effect
My first thought was to use GET, but later I did realize, when a client calls the API to download a file, the server also updates the counter in the DB indicating total number of downloads and the date of the last download.
Isn't this against the specification? The server state was changed, after all. Shouldn't this be a POST/PUT? But if the POST/PUT would be used, I wouldn't be able to share the link and use it from the browser.
Generating random list of values
In my case I need to call the API to generate random list of questions for a test (exam). The request doesn't change anything on the server, it just produces different response content each time the client calls it, so I guess using GET is alright. The indempotency applies only for the server state, not the result handed to the client, right? So is it allowed to request (GET) the same resource repeatedly with different outcome (as seen from the client)?
Generating list of values based on the user input
The last case is similar to the previous. I need the server to generate list of questions. This time based on the previous test's wrong answers. Again, the request doesn't alter server data, but I need to send to the server (relatively) long list of items, which wouldn't have to fit as a query string. That's why I would think a POST with a payload in the body could be used. But to be honest, it feels weird.
Is there a definitive answer which verbs to use for each case?
Downloading a file with a side effect
My first thought was to use GET
And that's the right answer. HTTP Methods are about semantics, not implementation.
HTTP does not attempt to require the results of a GET to be safe. What
it does is require that the semantics of the operation be safe, and
therefore it is a fault of the implementation, not the interface
or the user of that interface, if anything happens as a result that
causes loss of property -- Fielding (2002)
Generating random list of values
it just produces different response content each time the client calls it, so I guess using GET is alright.
Yup - again, as long as the semantics are safe, GET is a fine choice.
Generating list of values based on the user input
I need to send to the server (relatively) long list of items, which wouldn't have to fit as a query string. That's why I would think a POST with a payload in the body could be used. But to be honest, it feels weird.
So if you weren't worried about length of the identifier, GET would be the usual answer here, with all of the user input encoded into the URI.
At this point, you have a couple of options.
The simplest one is to simply use POST, with the user input in the message body, and the resulting list of values in the Response. That shouldn't feel weird -- POST is the method in HTTP with the fewest semantic constraints.
Alternatively, you can rethink your protocol such that the client is creating a "query resource", using the message body as the payload. So POST could work here again, or alternatively you could use PUT (with a somewhat different handling of the URI).
A third possibility is to look in the Hypertext Transfer Protocol Method Registry to see if there is an extension method with the semantics that you need, paying careful attention to whether or not the method is safe. SEARCH and REPORT might fit your needs.
If I decide later, I want to record each generated test to the DB, would you recommend to change the API to POST or keep it as it is? In case of changing the HTTP verb, the client wouldn't notice any functional change, but it would break the API, so semantics-wise, wouldn't it be more appropriate to use POST right from the start, after all? In both cases the meaning would be "create a new test".
No, but change things up a bit and things get interesting. The interesting bit isn't really "record to the database", but "be able to pull it out of the database later". When you start looking toward creating a new resource that can be retrieved later, GET stops being a good fit.
it would break the API
Only because you are ignoring an important REST constraint - REST api are hypertext driven. On the web, we can easily change from GET to POST by changing from a link to a form (or from a GET form to a POST form). The client isn't playing "guess the URI" or "guess the method" because the representation of state includes these details.
But yes, if you make a big enough change to the semantics, it's not going to be backwards compatible. So don't try to pretend that it is backwards compatible - just create a new protocol using new resources.
Reactjs is quite new to me but I am able to create my components and load them in the view etc.
I am creating a form with react which I want to get data to bind from my api or sending data to my api.
Of course, I want some user validation on my input fields but I have red that validation usually isn't done by reactjs itself. Now my question is; should I interact with a library as jQuery for validation or with the api response given the input arrows and place them in the view if they occurred?
Thanks!
You should always validate on server - even if you validate on client. That's rule we have to obey, amen.
Should you validate on client (React?). No, maybe, probably. Personal choice here.
I don't. I send data to server as is, validate there, process validation errors (if any) on client afterwards.
Why I don't?
- I don't like inline validation even before I submit form
- I don't like double work for one very same task (managing rules, syncing them across client and backend, ...), not to mention you have to handle error responses from server anyway.
Should you interact with jQuery?
Despite it's possible, don't. Do it in React land, will save you from issues with keeping UI in sync, ...
If you're using Redux, redux-form will offer you a great solution for form validation. It's a very simple and easy to use library.
All most all the resources about preventing SQL injection are talking about preventing it from fron-end and back-end ,with database level. Why do we need to do all those things?
Is it not enough to do it from front end, by just preventing the user from sending malicious SQL codes as inputs.
Because most client-side code can be bypassed since it executes on the client's machine. Basically any code that protects against bad input on the client-side is there to provide better feedback for an honest user and also to reduce low-hanging fruit type of attacks.
The back-end code is there to make sure any malicious user who bypassed your front-end security (with a crafted http request or w/e) will not be able to inject bad input into one of your SQL dynamic query. This is usually achieved by sanitizing input on the back-end and using parameterized queries.
Just because you button up your front-end doesn't guarantee SQL Injection safety. All the front end does is show pretty things to the user. The back end is where all the work is done and because the front-end must talk to the back-end in some way means you have a potential security issue.
I don't know if your application will be Winforms or a Web application, but that doesn't matter. I can use a program such as Process Explorer to manipulate the data that gets sent to your back-end, if its a Windows application.
If its a web application, then, similarly, I can use a tool such as Fiddler to manipulate the data that gets sent to your back end.
Moral of the story is always button up your back end and never let your back end assume that the data its getting from the front end is hunky dory!
Defense in-depth is a really, really good thing. Consider this, your app takes values as parameters to a query or perhaps even take user input to form a query. You do the right thing at the app level to correctly escape the input so injection attempts do nothing there and data is safely read or written to the database. Now, what if
the data that is written to the database itself is malicious code? The next stored procedure that reads from the table may now be executing random code.
the application code passes the "safe" data to the backend which is then used in a stored procedure or function (e.g. de-serialize, cast, etc...). Once again, you could be executing malicious code.
You could argue that instead of escaping the input, you could parse the input at the app level to strip/reject certain value, strongly type, regex everywhere, etc... but there are many situations where these restriction cannot be implemented because the app is intended to support free-flow text that may legitimately have suspicious looking characters especially if you support international character sets. (E.g. names, descriptions, notes, etc...).
Finally, do/should/can DBAs really count on the app or app dev to get everything right every time?
I am sending a request back to the server I am communicating with, the gist of this request will have a bunch of different parameters, like user ID, request number etc.
One of the more important parts of the request is a segment of XML that im hoping to create based of a few user selections in my interface.
Then at the end i will wrap this all up and send it off to the server...
However at the moment I have no idea how to form an segment xml, I have been reading this but im not sure how it relates to what I would like to do.
any help, example code, example tutorials or anything would be really helpful.
A plist is just xml with a strict dtd; and you can use NSPropertyListSerialization to create one to send back to the server from an NSArray/NSDictionary, very easily.