NotionCommotion

Hi Muddy, The returned users will be based on what the user types, and is an option and not always "joh". The question is regarding REST endpoints, and whether the get all users and search users should be the same endpoint. I've also read posts where people stated POST should be used for searches so that query parameters could be included in the body, but that just doesn't seem right.

Say I have the following API. GET /users # list of users GET /users/1 # get user with id 1 POST /users # create new user PUT /users/1 # modify user with id 1 DELETE /users/1 # delete user with id 1 GET /users will return the following: [ {firstname:"John",lastname:"Doe",email:"johndoe@example.com",phone:"(800) 555-1212"}, {firstname:"Jane",lastname:"Doe",email:"janedoe@example.com",phone:"(800) 555-2121"} ] Now I wish to return only users who's name starts with "Joh" and the client only needs first and last names. GET /users/Joh won't work as there is no user "Joh". It is my understanding that I should not use verbs and NOT do something like GET /searchUsers/Joh, correct? Should it be GET /users?term=Joh? For the limited data, should I just return everything and let the client deal with it, or have the client send another parameter in the URL to limit such as GET /users?term=Joh&format=minimal?

Curiosity is satisfied. Thank you Jacques1

Ah, that makes sense. I had a notion it might allow the server client better performance, but wasn't that serious about it, and was more curious whether such a technique was possible.

I think external APIs generally work. Take google maps for instance. In regards to keeping the key secret, maybe based on a limited time after client authenticates with webserver and limit to clients IP? Yes, I know client IP can be spoofed, but one would have to know when it was accessed. That being said, I don't think I need to get fancy, and will just proxy it (however, for curiosities sake, still would like to know if it could be done). Also, maybe an advantage to proxy is the web server could cache the API.

I too don't know of one, but would be surprised if there isn't one. How difficult would to take script from one of the big frameworks, and utilize it just for log-on authentication? If the logon script remains open source, and licencing concerns? Recommendations on which one to plagiarize?

The web servers are Drupal websites. They also act, however, as clients when they access the other server via cURL, and each Drupal website has its own API key. The clients I was referring to are browser clients operated by any person accessing the Drupal websites. Does this make sense? Also, what do you mean by "the outermost server"? Thanks

I have the following workflow. Web client logs on to web server and sets session cookie. Web client makes request to web server, and is allowed access by checking session. Responding to the request, web server makes a request to a different server utilizing cURL, and includes a secret API authentication key in the header. Other server makes sure the secret authentication key is valid, and responds with some data to the web server. Web server sends that data to the web client. Instead of having the web sever proxy the data from the other server to the web client, is it possible to have the web client directly request data from the other server without exposing the secret API authentication key? I was first thinking that the web client could make an initial request to the web server to receive a random value plus the secret authentication key encrypted with that random value, store both in a cookie, and send both to the other server which would unencrypt the key and return the data. But then I realized this does nothing. Any thoughts how this can be accomplished?

Thanks kicken, Yea, that is exactly what I am going to do. I've never used the TIME datatype before, but upon reading about it, agree it would work as it doesn't specify an instance in time (unlike DATETIME), but also agree it doesn't seem as flexible as a plan old INT.

Agree the user should not dictate how data is stored. But how is a duration (not an instant in time) stored as a date time field?

I could calculate the date using the following: $data=date(DATE_RFC3339,time()-$duration_in_seconds); I can calculate the seconds using on of the following: $seconds_per_hour=60*60; $seconds_per_day=24*$seconds_per_hour; $seconds_per_week=7*$seconds_per_day; $seconds_per_year=365.256366*$seconds_per_day; $seconds_per_month=$seconds_per_year/12; I just wish to store either the quantity of hours, days, weeks, months, or years based on how the user entered them. I will just store both the value in seconds, and in a second column, store the units so that I may be able to convert it back to the original format.

This is actually helpful! Maybe I don't need to later be able to display the time duration that was entered (i.e. 18 months). But instead, display the duration differently (1 year 8 months). But then again, if the user entered 58 weeks, this would be displayed as 1 year, 1 month and 2 weeks. I think 58 weeks is more intuitive.

Well, I don't know how deep, but thanks anyway. I am messing around with a database called influx which requires RFC3339 UTC time stamps in the WHERE clause. The user selects a duration such as 1 hour, 5 days, 3 years, etc. I then wish to calculate some aggregate value based on right now going back the given duration. I wish to store that duration in a SQL database so that I may do the query later. Thanks

I don't care about start and finish, but only duration. How long is the TV show you watched yesterday, requinx? Ah, one hour! How long would it be if you watched it today? I actually do care about start and finish, but start is always exactly right now.

I have an input field for time value and a select menu for the units (hours, days, weeks, months, or years) The application needs seconds (average is okay as not every month is equal, etc). I need to later be able to display the time duration that was entered (i.e. 18 months). Am I stuck storing the original value and the units?

I think both of you do Perfect. Exceptions, validation, some URL manipulation "yikes" and "even more yikes" dynamic SQL.

I can answer what I think is unambiguous, but I can't answer what the majority of PHP programmers consider proper, and I would like to be consistent with the greater majority (of good coders). Would you say the only time it is acceptable is when the variable has either white space or a double quote on either side? Furthermore, only simple variables and maybe objects, but not arrays?

Hi Jacques1, I've already made a change to using it when arrays and objects are involved. I should have asked whether something like this is considered bad practice. If not, where should one draw the line? $color="brown"; $string="The $color cow jumped over the moon.";

I agree it is easier to read and less prone to errors, and have recently made an effort of using it for anything in the slightest ambiguous. I am starting to think even that might be too lax, and leads to inconsistencies. Maybe a better question is whether you believe simple syntax should ever be used?

I've read the manual http://php.net/manual/en/language.types.string.php#language.types.string.parsing, and know when it has to be used. When should it be used? For instance, is $url1 or $url2 considered better practice? Are their other common scenarios where complex syntax is not required, but should be used? $this->a='aaa'; $arr['c']='ccc'; $url1="$this->a/foo/$arr[c]/bar"; $url2="{$this->a}/foo/{$arr['c']}/bar";

Dang, that must be some good hot chocolate! Does the Fibonacci algorithm have anything to do with what I am trying to accomplish, or is it just an example of recursive linear implementation?

I have the following array of objects represented by the below JSON. [ {id: 123, type: "aggr", duration: 10, offset: 30, timestamp: 444, foo: "bar"}, {id: 223, type: "aggr", duration: 20, offset: 40, timestamp: 333, foo: "bar"}, {id: 323, type: "aggr", duration: 10, offset: 30, timestamp: 222, foo: "bar"}, {id: 523, type: "aggr", duration: 20, offset: 40, timestamp: 444, foo: "bar"}, ...... {id: 623, type: "aggr", duration: 20, offset: 30, timestamp: 444, foo: "bar"}, {id: 723, type: "aggr", duration: 10, offset: 30, timestamp: 666, foo: "bar"} ] I need to group them based on common duration and offset pairs. For instance, element 0, 3, and N-1 all share this pair. Also, I will take different action based on the timestamp value of each object with a given duration/offset pair. I will have built this array of objects in some other code, and could if I want restructure it. Instead of an array of objects, I was thinking of an object who's property names are the duration/offset pair, and their values are arrays which include id, type, etc objects. But a property name is only a single string so I thought maybe I could concatenate the two pairs into one. Seems like a hack, and it would been haven nice if the property name was identified by two strings (duration and offset).

Thanks Jacques1, Wow, bet you didn't think I was capable of a non-hypothetical question Yes, a custom point can contain other custom points. Agree, array_keys() is better suited, and will do so. Getters, Setters, and now Loaders.... Sure, I like it!

Thanks Requinix Why not a static variable? Everyone says the're evil for one. Secondly, does it make unit testing difficult? Would the method still be normal and not static? Agree the properties would definitely be public, but it still seems a bit shady. I see your point about a class with a single method being a little overboard. For the non-recursive idea, something like: while(!empty($stack)){ //do stuff which adds and removes from the stack until empty... }

I was thinking of something like the following. Or maybe putting each in an array or object, and then just passing that back. private function _setPoints(array $items, $realPointIDs=[], $realPoints=[], $cacheReal=[], $aggrPoints=[], $aggrPointIDs=[], $cacheAggr=[], $custPointIDs=[], $custPoints=[]) { // bla bla bla $this->_setPoints($customNew, $realPointIDs, $realPoints, $cacheReal, $aggrPoints, $aggrPointIDs, $cacheAggr, $custPointIDs, $custPoints ); } }