In the path:
Format: http://mydomain.com/{category}/{subcategory}/{pageNumber}/{pageSize}
Example: http://mydomain.com/books/thriller/3/25
In the querystring:
Format: http://mydomain.com/{category}/{subcategory}? pageNumber={pageNumber}&pageSize={pageSize}
Example: http://mydomain.com/books/thriller?pageNumber=3&pageSize=25
I like having everything on the path, but my problem with that is that while it is obvious (or at least somewhat obvious) what "books" and "thriller" are in first example, the "3" and "25" seem pretty arbitrary by contrast.
Is there a canonical method for determining what goes where in MVC, or is it really just up to the dev?
I prefer things like pagenumbers to be in the querystring variables. I think there's a difference in descriptiveness between
http://mydomain.com/books/thriller?pagesize=50&page=4
and
http://mydomain.com/books/thriller/50/4
The point (to me) of having clean url's is for them to be more descriptive and readable, and I find the first example to be just that.
One interesting point made byJohnRudolfLewis is:
One rule of thumb that I follow is
that if the argument is required,
consider using the path, if the
argument is optional, always use
querystring arguments.
One rule of thumb that I follow is that if the argument is required, consider using the path, if the argument is optional, always use querystring arguments.
Overall, I'd stick to whatever makes the url look more readable.
This site puts it in the querystring: https://stackoverflow.com/questions?page=2&pagesize=30
Well, it's obviously up to you. But, you're designing a RESTful interface that's supposed to be human readable. The querystring is much better in that regard. Otherwise you're looking at two numbers that could really be anything. And who's going to remember the order?
Is there a canonical method for determining what goes where in MVC, or is it really just up to the dev?
It's up to you.
MVC is about the organization/flow of your server-side code and seperating the view from the business layer, not so much about query parameters.
You could also consider the following
Format
http://mydomain.com/{category}/{subcategory}/page/{pageNumber}/results/{pageSize}
Example
http://mydomain.com/books/thriller/page/3/results/25
It is pretty much up to the dev. I would say put the pageSize in the URL.
Related
Say I want to consume an API that returns JSON-LD and follow all the links. (I'm experimenting with the Hydra API-Demo, but it should work with all JSON-LD APIs, not only Hydra-based ones. Any good APIs out there that I should try?)
So I want to follow all the links and my environment doesn't have native RDF support. Probably, I should first parse it with one of the libs and get it into extended form with jsonld.expand(). Then I just grab all the values with key #id. Is that the recommended way to do it or am I missing some edge-cases?
The purpose of the expansion API is to produce regular, context-free output (expanded form) for algorithmic processing -- which is exactly what it sounds like you want to do. So, yes, you've got the right approach; you shouldn't be missing any edge cases as I've understood you. After you have JSON-LD in expanded form, you can easily follow the #ids (and, if you also need to do some kind of analysis of the vocabulary/ontology, you can follow the properties which will then be fully-expanded URLs).
If a user enters a form of the word "look" such as "looked" or "looking", how can I identify it as a modified version of the verb look? I imagine others have run into and have solved this problem before ...
This is part of a fairly complicated problem called Stemming
However it's easier if you only want to take care of verb. To begin with, you can try the naive lookup table approach, since English vocabulary is not that big.
If you want something fancier, check the wiki page above.
If a regex is what your looking for something like this works look.*?\b to match look , looked and looking
Depending on your task, WordNet can be your friend for stuff like this. It's not a stemmer, but most stem words will return hits for what you're looking for It also provides synonyms and a lot of other information if you care about the concept 'look' rather than the word itself.
UPDATE: It was suggested in the comments that I create a wiki for this. I have done, you can find it here (should you wish to keep tabs on it and/or contribute).
http://vrs.tomelders.com
I've never worked on anything like this before, so I'm completely winging it.
I've never worked on anything like this before, so please
I'm want to work on an open "standard" or "language", or... well, I don't really know what to call it.... to make form validation easier. I'm calling it VRS (Validation Rule Sheets) but at this stage, everything is negotiable.
The idea is to create a sheet of rules, similar to CSS that define how forms should be validated. This will require
A Syntax / Specification
A VRS Parser to convert the VRS into something useable
A VRS Processor to compare the form data against the rules and return a response.
A response format.
The benefits of a system like this would be
A platform/language agnostic way to define form validations.
A cross platform, highly portable way to define form validations.
Easy to read, easy to setup, easy to modify.
Client side and backend integration.
First things first though. What should the syntax / specification look like.
The way I see this working online is that a VRS file could be specified as a hidden field and the application routes the supplied form data through the VRS processor before processing it.
By way of an example, you could validate the content type of the "name" field would look like this
name {
content-type: alpha;
}
content-type could be one of three values: alpha, numeric or alpha-numeric.
Hopefully that makes sense. I've never done anything like this before so I'm eager to get other peoples input. Here's as far as I've gotten
------------------------------------------------------------
content-type: (string) alphanumeric | alpha | numeric
Restricts content to either numeric, text or alphanumeric.
------------------------------------------------------------
is-fatal: BOOL
If the rule fails, is it fatal? This could be really useful
for AJAX responses.
------------------------------------------------------------
allow-null: BOOL
wether a field can be empty or not. Good for required fields
and checkboxes
------------------------------------------------------------
pattern-match: (string) email | url | regex
match the field against a pattern.
------------------------------------------------------------
field-match: (string) field_name
compares a field to another field. eg: password confirmation
------------------------------------------------------------
greater-than: INT | FLOAT
less-than: INT | FLOAT
within-range: INT | FLOAT, INT | FLOAT
Pretty self explanatory. With regard to strings however,
the string length is compared against the params.
------------------------------------------------------------
is-unique: (func) connection(host,user,pass), (func) map(table, field)
Check the value against a field in the database to see if
it's unique.
------------------------------------------------------------
date & time validations
This i'm a bit worried about in terms of terminology. I also
want to include dynamic vars in VRS such as
#now
#today
#thisMonth
#thisYear
------------------------------------------------------------
before: STRING | VAR
after: STRING | VAR
Again, self explanatory. Although I'm unsure what the date/time
format should be. UTC?
------------------------------------------------------------
Elapsed Time:
I'm completely stuck on how to handle conditions like
"years elapsed since date is more than 16"
I don't relish the idea of rules as prolix as
years-elapsed-since-now-are-more-than:18;
years-elapsed-since-now-are-less-than:18;
Finally, I'm debating wether devs should be able to specify the errors/warnings in the VRS or should they do that when handling the response?
So, that's a lot to take in and I hope it's clear. My question(s) I guess are
Good idea / bad idea?
Is this the right kind of syntax?
Are there more elegant ways of naming the rules.
What's missing.
thanks
UPDATE: A few people have stated that this proposed system is a bad idea. If you think so, please provide a scenario in which it wouldn't work. Thinking it's a bad idea is one thing, proving it's a bad idea is another, and I'd like to see proof that it's a bad idea sooner rather than later. If you really think form validation could not be made easier or less tedious, please explain why.
In addition, I'm aware that form validation is not a new issue. However, there is currently no portable, cross platform, cross language solution to address form validation, which is what this proposal is specifically addressing.
I like the idea of putting the error messages in the VRS too. But they should specific to the rule that failed.
Also, you might consider not developing an entirely new "language" but use something like YAML for which parses already exist.
I see this language as being useful as you could use the same VRS for both client- and server-side validation.
PS: This should be community wiki methinks.
I suppose it is a good idea, if you can maintain it yourself.
Remember, your making the syntax. It's up to you (so long as it looks decent).
no, not really. So long as the names are obvious (look like what they are), and aren't too long or confusing, then the're fine.
Perhaps you should note default values for the rules when they aren't specified.
Good idea / bad idea?
Generally, this kind of thing is a bad idea. That's what PHP is for.
What's wrong with http://www.phpformclass.com/
http://www.x-code.com/vdaemon_web_form_validation.php
or other PHP form management tools?
Is this the right kind of syntax?
No. What's wrong with PHP? It has good syntax for this kind of thing.
Are there more elegant ways of naming the rules.
Yes. PHP object classes. Numerous Other projects. You're not the first person to validate form input.
What's missing.
Answering the fundamental question: What's wrong with PHP?
A list of related projects that already do this and specific reasons why your project is better than all the other ones already out there.
Am wondering if the combination of trim(), strip_tags() and addslashes() is enough to filter values of variables from $_GET and $_POST
That depends what kind of validation you are wanting to perform.
Here are some basic examples:
If the data is going to be used in MySQL queries make sure to use mysql_real_escape_query() on the data instead of addslashes().
If it contains file paths be sure to remove the "../" parts and block access to sensitive filename.
If you are going to display the data on a web page, make sure to use htmlspecialchars() on it.
But the most important validation is only accepting the values you are expecting, in other words: only allow numeric values when you are expecting numbers, etc.
Short answer: no.
Long answer: it depends.
Basically you can't say that a certain amount of filtering is or isn't sufficient without considering what you want to do with it. For example, the above will allow through "javascript:dostuff();", which might be OK or it might not if you happen to use one of those GET or POST values in the href attribute of a link.
Likewise you might have a rich text area where users can edit so stripping tags out of that doesn't exactly make sense.
I guess what I'm trying to say is that there is simple set of steps to sanitizing your data such that you can cross it off and say "done". You always have to consider what that data is doing.
It highly depends where you are going to use it for.
If you are going to display things as HTML, make absolutely sure you are properly specifying the encoding (e.g.: UTF-8). As long as you strip all tags, you should be fine.
For use in SQL queries, addslashes is not enough! If you use the mysqli library for example, you want to look at mysql::real_escape_string. For other DB libraries, use the designated escape function!
If you are going to use the string in javascript, addslashes will not be enough.
If you are paranoid about browser bugs, check out the OWASP Reform library
If you use the data in another context than HTML, other escaping techniques apply.
Are there any naming conventions or standards for Url parameters to be followed. I generally use camel casing like userId or itemNumber. As I am about to start off a new project, I was searching whether there is anything for this, and could not find anything. I am not looking at this from a perspective of language or framework but more as a general web standard.
I recommend reading Cool URI's Don't Change by Tim Berners-Lee for an insight into this question. If you're using parameters in your URI, it might be better to rewrite them to reflect what the data actually means.
So instead of having the following:
/index.jsp?isbn=1234567890
/author-details.jsp?isbn=1234567890
/related.jsp?isbn=1234567890
You'd have
/isbn/1234567890/index
/isbn/1234567890/author-details
/isbn/1234567890/related
It creates a more obvious data structure, and means that if you change the platform architecture, your URI's don't change. Without the above structure,
/index.jsp?isbn=1234567890
becomes
/index.aspx?isbn=1234567890
which means all the links on your site are now broken.
In general, you should only use query strings when the user could reasonably expect the data they're retrieving to be generated, e.g. with a search. If you're using a query string to retrieve an unchanging resource from a database, then use URL-rewriting.
There are no standards that I'm aware of. Just be mindful of IE's URL length limit of 2,083 characters.
Standard for URI are defined by RFC2396.
Anything after the standardized portion of the URL is left to you.
You probably only want to follow a particular convention on your parameters based on the framework you use.
Most of the time you wouldn't even really care because these are not under your control, but when they are, you probably want to at least be consistent and try to generate user-friendly bits:
that are short,
if they are meant to be directly accessible by users, they should be easy to remember,
case-insensitive (may be hard depending on the server OS).
follow some SEO guidelines and best practices, they may help you a lot.
I would say that cleanliness and user-friendliness are laudable goals to strive for when presenting URLs.
StackOverflow does a fairly good job of it.
I use lowercase. Depending on the technology you use, QS is either threated as case-sensitive (eg. PHP) or not (eg. ASP). Using lowercase avoids possible confusion.
Like the other answers I've not heard about any conventions.
The only "standard" I would adhere to is to use the more search engine friendly practice of using a URL rewriter.
There are no standards that I know of, and case shouldn't matter.
However within your application (website), you should stick to your own standards. For your own sanity if nothing else.