Ok, this is probably something answered millions of times, but I couldn't find an answer on Google (maybe I'm using the wrong parameters?).
Here is the thing:
I'm planning to implement a REST webservice using PHP. This webservice is supposed to serve a mobile app and also a website (located on the same server/virtualhost/whatever).
For example, URLs will be something like:
http://www.somedomain.com/API/ (RESTful webservice)
http://www.somedomain.com/ (WebSite, which will fetch data from the same sources that the webservice uses).
Now my question is:
Which type of query is the most recommended for querying the database? For example, if I login from the website (http://www.somedomain.com/), it would be better to implement another internal PHP API for that or to login using cURL to the REST API and why?
I know, if I implement another PHP function for login from the website, I will be using one less HTTP connection to my server, but wouldn't it break the idea of the RESTful API?
Thank you in advance.
I'd say you want to leave out the HTTP round-trip where you can. That's potentially extremely wasteful, though if the calls are rare then it may be worth it for the code de-deduplication. It all depends on your application really.
Don't worry too much about "breaking the RESTful API" — by your logic, your own application should have no function calls and just be full of curl invocations to itself. No, instead, at some point, your code needs to shake off the management speak and just get down to bloody work. :)
I am sure most of you know this, but for the sake of completeness:
A function or procedure is a designated program-section that handles a specific task and usually consists out of a function declaration or definition and a function body.
When a function is called remotely, it is known as a remote procedure call (RPC), and the invocation implementation as a Remote Procedure, which is generally handled by an RPC- API and in rare cases by an ABI.
So at the heart of your quest lies questioning the necessity for remote procedure invocation, and how much a given procedure should perform. As such heeding good code-refactoring guidlines is a good start to a good API. I generally adhere to the following pointers:
If you do not need the necessity of remote invocation for a given procedure, do not expose it unnecessarily.
Choose wisely which procedures you make API accessible and unit-test them.
Create various wrapper functions which successively call a set of local functions to perform specific tasks as opposed to calling each function remotely, and render them accessible to the REST API.
An initial authentication procedure is a good idea, but I would recommend using established protocols such as OAuth 2 rather than implementing your own. As such may end up using curl in your remote php script.
This should get you started.
Other than that you do not provide enough information to give you a more specific answer. I would generally recommend to look at google, yahoo, facebook, and perhaps NCBI's PUG to see how they implement their REST APIs, which are often a good case-study.
Related
Being relatively new to web development, at least using client side technologies such as the AngularJS framework, I need to resolve a few queries before I can start my latest project.
I am writing an application using the AngularJS which reads/writes/updates data in a database. With javascript being client side I have chosen to write a PHP REST API to do the database queries, resulting in a secure username and password and a single database layer.
My question is, given my REST API, I will be using AJAX from javascript (which is client side) to invoke methods. How do I stop other sites from writing a script to invoke the REST API as well? Putting an authentication token in the javascript code isn't very secure, someone can just copy it.
Is a REST API the best approach for this problem? I am not adverse to learning new technologies or practices so please, any thoughts on better design patterns or methods of implementation are greatly appreciated. Unfortunately, due to my limited domain knowledge in this area, I have been unfruitful in my Google Searches as I'm not confident of the terms under which I should be searching.
Many thanks.
Since your Angular application is living in the browser, your REST API will need to be publicly accessible from any random visitor's browser. You thereby have a public API, out of necessity. You can't restrict it; either visitors can see the data or they can't.
Essentially this is not significantly different from a traditional webpage though. In a server-side generated page, you output your data packaged as HTML and deliver it to anyone who asks. In a REST-API/Angular app, you deliver the data packaged as JSON to anyone who asks. Either way the data is equally public, though maybe the REST API is a little easier to "abuse" than scraping the HTML would be. It may be useful to deliberate employing some user behaviour tracking and throttling, if you want to avoid someone outright sucking all of your database dry; this applies equally to JSON based REST APIs as it does to regular web pages.
If you're also exposing read/write APIs this way, you're of course wide open to abuse.
The only way to make an API non-public is to require password authentication. If the users of your site must be logged in, then you can restrict the API to anyone with a valid session. This doesn't help much in the grant scheme of things if anyone can simply register an account on your site, but it needs more deliberation and provides slightly more manageability than a completely open API.
Admin-only APIs of course must be protected in this way, requiring an account which only you have the credentials to.
Being relatively new to web development, at least using client side technologies such as the AngularJS framework, I need to resolve a few queries before I can start my latest project.
I am writing an application using the AngularJS which reads/writes/updates data in a database. With javascript being client side I have chosen to write a PHP REST API to do the database queries, resulting in a secure username and password and a single database layer.
My question is, given my REST API, I will be using AJAX from javascript (which is client side) to invoke methods. How do I stop other sites from writing a script to invoke the REST API as well? Putting an authentication token in the javascript code isn't very secure, someone can just copy it.
Is a REST API the best approach for this problem? I am not adverse to learning new technologies or practices so please, any thoughts on better design patterns or methods of implementation are greatly appreciated. Unfortunately, due to my limited domain knowledge in this area, I have been unfruitful in my Google Searches as I'm not confident of the terms under which I should be searching.
Many thanks.
Since your Angular application is living in the browser, your REST API will need to be publicly accessible from any random visitor's browser. You thereby have a public API, out of necessity. You can't restrict it; either visitors can see the data or they can't.
Essentially this is not significantly different from a traditional webpage though. In a server-side generated page, you output your data packaged as HTML and deliver it to anyone who asks. In a REST-API/Angular app, you deliver the data packaged as JSON to anyone who asks. Either way the data is equally public, though maybe the REST API is a little easier to "abuse" than scraping the HTML would be. It may be useful to deliberate employing some user behaviour tracking and throttling, if you want to avoid someone outright sucking all of your database dry; this applies equally to JSON based REST APIs as it does to regular web pages.
If you're also exposing read/write APIs this way, you're of course wide open to abuse.
The only way to make an API non-public is to require password authentication. If the users of your site must be logged in, then you can restrict the API to anyone with a valid session. This doesn't help much in the grant scheme of things if anyone can simply register an account on your site, but it needs more deliberation and provides slightly more manageability than a completely open API.
Admin-only APIs of course must be protected in this way, requiring an account which only you have the credentials to.
I am creating an app for my clients to add to their webpages. however, I am hosting the database that stores the info for this app. All I want to do is do all the queries on my server and somehow pass the $var to their server.
so what I was thinking was to have my PHP page with all the MYSQL credentials store on my server and give them a code that calls that page and outputs the stuff, something like
require_once('192.163.163.163/config.php');
But I bet this is the least secure way to do this. I don't want to give anyone access to the central database and I am handling all the requests. Do you guys have any suggestions that I can pull the data off my db and pass it to their server in a $var without opening any doors?
If you can't afford to give away your DB credentials or other internal details of your system but you need the clients to be able to read data from you, then the only really secure way to do set your system up as an API that the clients can call.
Don't try to combine the two systems into a single app; it will open up holes that cannot be closed.
To create an API is fairly simple in principle. Just create a suite of normal PHP programs that accept a set of pre-defined arguments return the data in a pre-defined format that can be easily processed by the calling program -- eg maybe a JSON structure.
The clients would then simply call your system via an HTTP call. They'd never need to see your code; the wouldn't need to be hosted on the same server, and they wouldn't even need to be writing their system in the same language as yours.
There's a lot more to it than that -- it is, of course, perfectly easy to write an insecure API as well, and you'll want to read up on how to write a good API to avoid that sort of thing -- but that's your starting point. I hope it helps.
I am new to the world of PHP and coding as those have helped me answer a number of questions I have posted know. I have the opportunity to jump into the deep end however seeing I have no clue about PHP and web services, I am seeking your help. I would appreciate it if you could point me in the right direction as I have not been able to find any examples nor detailed information regarding it.
Effectively there is a PHP page that needs to pass certain values to a .NET web service i.e. name, email, mobile number and upon the receipt of such information the web service sends out a text message. This is information I have so far
The Allocation service uses a basic HTTP binding and TransportWithMessageCredential security.
Sample C# code using a reference generated with Visual Studio tooling
Allocation.AllocationServiceV3Client Client = new Allocation.AllocationServiceV3Client();
Allocation.AllocateResult Result;
string VoucherCode;
DateTime ExpiryDate;
string DisplayMessageText;
Client.ClientCredentials.UserName.UserName = ? ;
Client.ClientCredentials.UserName.Password = ? ;
Result = Client.AllocateToConsumerMobileAndSendSMS(out VoucherCode,
out ExpiryDate,
out DisplayMessageText,
ClientID,
ClientReference,
CampaignID,
ActivityID,
MobileNumber);
if (Result != Allocation.AllocateResult.Success)
{
}
I have no clue about PHP and web services
First things first, pick your brain up out of the C# soup and sit it out to dry off for a few hours. PHP is a simple language for simple things. If you're new to it, you don't want to try and make it do complex things, and you certainly don't want to try writing C# style code in PHP.
Let's take "web services" as an example of a "complex" thing. In some circles, this means horribly designed monstrosities like SOAP. VS makes it relatively easy to build SOAP bindings to your existing classes, so it's not a painful solution for you.
SOAP is a very painful solution for PHP.
Effectively there is a PHP page that needs to pass certain values to a .NET web service
It sounds like you have an existing web service set up then, correct?
You could try and use the built in SOAP client, but it's an undebuggable and unconfigurable binary blob of horrors that will make you want to kill someone if it doesn't work for you immediately.
Edit: The section below was written incorrectly assuming that both sides were under your control. As this is not the case, you can disregard the rest of the answer. I'm leaving it up because it may be valuable to others.
I would advise a different approach. Set up an endpoint (URL) in your .NET application that expects the data you've specified as POST values, and have PHP POST the data. This has the distinct advantage of being incredibly simple. Because you're new to PHP, simple is a big win.
(In other words, ditch the "web service" -- or make a parallel copy if other things consume that service already.)
PHP comes with a service called PEAR, a repository of helpful classes. You can use HTTP_Request2 to quickly build the HTTP POST request. Chances are that it's already installed. If it isn't, it's easy to install either at the system level using the pear command, or locally in your project.
Here's some quick example code copied straight out of the reference guide:
$request = new HTTP_Request2('http://www.example.com/your/endpoint/url.foo');
$request->setMethod(HTTP_Request2::METHOD_POST)
->addPostParameter('name', '...')
->addPostParameter('email', '...')
->addPostParameter('mobile', '...');
$response = $request->send();
You can then read the response as needed.
Now, this isn't a perfect solution. Your C# code mentions a username and password, which I suppose could be included in the POST data. You could also use HTTP authentication (supported by HTTP_Request2) instead.
Ok, now from what I understand, C# will make a request to the php page, wich then (in simple html) gives it back some data.
PHP Is made to do some calculation serverside and when it's done it will send the prints and echo's to the client side as html (simple explanation)
If you want to start using php you would be best off getting into the basics by following the tutorials at W3School (http://w3schools.com/php/default.asp)
Then you can use http://php.net as a reference for more functions you might need.
The way you'll want to set it up is for C# to make a request to a page like action.php
And then using a $_GET method to get the data so C# would send a request to
action.php?userid='456'
I am defining out specs for a live activity feed on my website. I have the backend of the data model done but the open area is the actual code development where my development team is lost on the best way to make the feeds work. Is this purely done by writing custom code or do we need to use existing frameworks to make the feeds work in real time? Some suggestions thrown to me were to use reverse AJAX for this. Some one mentioned having the client poll the server every x seconds but i dont like this because it is unwanted server traffic if there are no updates. I was also mentioned a push engine like light streamer to push from server to browser.
So in the end: What is the way to go? Is it code related, purely pushing SQL quires, using frameworks, using platforms, etc.
My platform is written in PHP codeignitor and DB is MySQL.
The activity stream will have lots of activities. There are 42 components on the social networking I am developing, each component has approx 30ish unique activities that can be streamed.
Check out http://www.stream-hub.com/
I have been using superfeedr.com with Rails and I can tell you it works really well. Here are a few facts about it:
Pros
Julien, the lead developer is very helpful when you encounter a problem.
Immediate push of new feed entries which support PubSubHubHub.
JSon response which is perfect for parsing whoever you'd like.
Retrieve API in case the update callback fails and you need to retrieve the latest entries for a given feed.
Cons
Documentation is not up to the standards I would like, so you'll likely end up searching the web to find obscure implementation details.
You can't control how often superfeedr fetches each feed, they user a secret algorithm to determine that.
The web interface allows you to manage your feeds but becomes difficult to use when you subscribe to a loot of them
Subscription verification mechanism works synchronous so you need to make sure the object URL is ready for the superfeedr callback to hit it (they do provide an async option which does not seem to work well).
Overall I would recommend superfeedr as a good solution for what you need.