Basically, let's suppose an application that manage some user's meetings.I have a filtering zone on a page that aims to specify the category of items I need to specifically return.           Supposing two kind of filters:            Retrieving my actual meetings (meetings currently occurring or planned in the near future)        Retrieving my past meetings (meetings that are already past)            I think of passing a kind of url parameter like this:             www.myapp.com?me=actualorwww.app.com?me=past Indeed, I can't have both actual and past in the same call since it would not be appropriate for the listing.            So in my server side, I would handle through a simple conditional the passed value to filter the query.Is it right enough to pass a string like this (past or actual) or is there a better practice to handle this case?Note that by default, meaning without filtering, all meetings are returned.
Good practice to pass this information through URL parameter
architecture;web applications;parameters;url
Totally standard. Even if both options could be used in parallel you could use something like me=actual;past and split on the server. I think the URL should read something like www.myapp.com/meetings?me=actual (in case you would have more functionality than just meetings and maybe want to go for RESTful routing right away or later)With how URLs work the other option would be to have something like www.myapp.com/actual_meetings and www.myapp.com/past_meetings which would become ugly rather soon and at least for frameworks like Rails that use RESTful routes would need some extra work where not necessary. Also this has not very much flexibility in case you need to add more options, not too mention other cases where you have options are dynamically generated from database entries.Some things may depend on your background technology of course, but for most websites you will see params used for such small details where one controller action can handle such very similar requests (where the difference is mostly a detail in the SQL query and all the business logic and view rendering of html stay the same anyway)From a REST perspective this would be rather obvious, since meetings are clearly a REST resource and what you do would just call the index action (therefore www.myapp.com/meetings in plural) and which meetings to show only a matter of those params.