Sorry in advance if my wording is wrong because I'm not quite sure how to explain what I want, so I'll just describe the end result.
I have a php based excel tool called socialcalc(it was wikicalc before). I want to allow users to connect to a database and pull live data onto the sheets(so they can run calculations on it).
I understand that for sure socialcalc will have to query mysql but I'm trying to figure out the most effective way. Is it better to allow it to query it directly? or should I have it query the database an get an xml file as a result? Or what other ways would you suggest is a efficient and secure way of allowing read access to the data?
We're building alot of the this ontop socialcalc from scratch so pretty open to all solutions but ultimately, we want this to power other services.
Update: to clarify, I am looking for suggestions on using SOAP/XML over say directly querying the database or using HTTP POST/GET,etc..which type of service layer would you suggest or what are the factors to consider when choosing?
"Simple is better than complex."
You could certainly implement a Web Service layer between your application and MySQL, but ask yourself why you would want this. You might want it because:
You plan on changing backend systems at some point in the future and don't want to have to refactor business logic in the front-end application
You want to expose your backend data to other applications and provide a common interface for doing so
You want to implement smoe sort of caching/persistence strategy in the middle tier
All of those would be valid, good reasons to use a Web Service layer between your application and your database. Certainly there are more valid, good reasons as well.
If you can't think of a reason why you should implement a Web Services layer, then don't, it's that simple. You can always decide to later when there is a good reason.
EDIT:
So you've decided to go ahead with the Web Service...congrats! I think in that case you should look at two key frameworks to save you a lot of time:
Get a good ORM framework that can generate the vast majority of your CRUD logic. Doctrine is a popular choice for PHP.
Use a Web Services framework for implementing your interfaces and business logic. I've done this in the past using the Zend Framework, as they support both XML and JSON payloads via REST. XML and SOAP are great if you need strict data validation requirements, but if you're the only one consuming your own Web Service, you don't need to impose such limiations on yourself, as you know your requirements. In that case, JSON should be sufficient.
By the way, I've discussed RESTful services via Zend in another previous question:
lightweight RESTful PHP server
I think the best approach is by using a step-to-step action.
Sep one
Let the user choose the data he want to implement in his excel sheet. How to do this is up to you.
Step two
Submit the choise of the user to a own created SQL API. This API will check the input for injections and so on and will do all the query en retrieval of data.
Step three
Send teh retrieved data to a class which will create the excel file.
Step four
Send the created excel file to the user.
The most importent part of this is the SQL api. This is a class which handles all the input from the user and communication with the database. It can use normal SQL statements but you cna use it to validate all the data.
Hopefully this is some use for you.
Related
Im confused regarding the need of REST for a web service.Im a noob when it comes to web service,the scalability etc.
This is my requirement
-Need to fetch some data eg:names of students in a class and their photographs plus their address and stuff
-There is no authenciation/Tokens required since the data is publicly available
My question is
-Do i need to use REST for this? Will MYSQL+PHP Webservice that communicates using HTTP GET and POST do the job?
-If i go with this approach will this affect the performance of the app,when there is bulk data and will it scale?The maximum number of users that may be using the app is just 50 at a time.
-Does REST offer significant advantages,since i dont know JSON and stuff,will it payoff the learning curve?
It's better to use REST. You can just post your data as HTTP or as JSON and then process this data in your function and return result as JSON .
I recommend you to use CakePHP or Yii because it's easy to use.
In case of bulk transaction you can use MongoDb as your database.
What I would say is that REST describes a way to leverage HTTP features and use them in an optimal way. Otherwise you don't have to use all the REST mechanisms to implement a RESTful application.
I think that this link could help you to understand how to implement a Web API (i.e. a RESTful application):
Designing a Web API: https://templth.wordpress.com/2014/12/15/designing-a-web-api/
Here are my answers to your questions:
REST doesn't require an authentication to access resources. However REST integrates authentication mechanisms based on the HTTP header Authorization.
REST describes good practices in using HTTP but of course, you're free to use it as you want ;-) REST recommends to use the HTTP methods for what they actually are. To be short, GET to retrieve data, PUT / POST to update data (POST mainly to add data and PUT to update them) and DELETE to delete data. POST can also be used for what we can see as actions. REST also uses specific URIs with path variables. If I use your example, the URI for a list of students within a class would be: /classrooms/<classid>/students. REST also define a mechanism to request specific content format such as JSON based on the header Accept. In fact, you're generally familiar with most of these aspects if you implement Web applications for some years and REST provides you a way to design your application to leverage them at best.
Regarding performance, I would say no. One of the key aspect of REST is that RESTful applications are stateless. No state must be handled on the server side. This allows applications to scale more readily. I don't see any reason for bad performances regarding bulk updates. In fact, it's up to you to handle them. REST leaves the choice of the data format content sent to the server and the way to handle them efficiently on the server side. You can consider using either synchronous and asynchronous approach. For the asynchronous approach, you should return an HTTP status code 202. This approach can allow you to control the work load of updates for concurrent users. You could add the bulk updates to a queue and handle them after one per one in a separate process or thread. An example of RESTful application that uses bulk updates is ElasticSearch. See this link: http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/bulk.html.
The main advantage of REST is that it allows you to leverage HTTP mechanisms at best. Another thing that comes to mind is that there is now some tools allowing you to generate client kits to consume your application and generate documentations about the contract of your RESTful applications. See Swagger (Swagger, Swagger UI, Swagger Codegen) and RAML. These links can help you: http://swagger.io/ and http://raml.org/. Another tool, Restlet Studio (http://studio.restlet.com/#/), can help you to understand all these concepts since it comes with a sample application. Regarding the learning curve, I don't think that it's too much important since if you already implement web application, you know most of concepts.
Regarding the format you would use for content, JSON seems to be a good fit. However REST doesn't enforce any content kind. It provides a mechanism to request a specific content (Conneg, i.e. content negotiation based on the header Accept) but you don't have to use it. REST let you the way to manage this content within your application.
Hope it heps you,
Thierry
You can implement any protocol you want to do that, but using REST ensure you are following a common procedure which will make your application more maintainable.
The amount of resources used depends how do you implement the queries and responses on the server-side.
You should learn that, it will improve your knowledge as you can learn together other patterns (gateway, repository, MVC) to make your server-side professional and maintainable.
My suggestion for your application is implementing the server-side using a framework such as Laravel (I recommend), CakePHP or similar. I say that because your app seems to be just interaction with pre-defined models.
So I have a simple jQuery Mobile site interfacing with a MySQL database via PHP. Users orders are queried initially, then updated using the mobile web interface. I am not using any PHP framework, just 7 or 8 PHP files I've written for retrieving, updating, creating, and deleting order records.
As I begin to develop the Android and iOS applications, I realized it would be beneficial to have a PHP backend framework that can handle requests to create/read/update/delete my orders and users records from any of the 3 sources without caring which one it is. I want to create a layer of abstraction between the server side database handling and each of the 3 mobile interfaces. I envision being able to make a POST call from the client side, passing a TYPE argument and a JSON array of the data to a generic page like /myserver/mRequest.php, which would determine what to do based on TYPE and handle the processing, returning a STATUS variable and a JSON array of data back to the client.
Is there a good (preferably free) PHP framework that will help layout the backend? I've looked at Zend and a few others, but they seem pretty heavy and intended for desktop sites. I want to minimize the number of calls to the server as well as the amount of data thats sent back and forth (we all know how slow Verizon 3G is).
I'm hoping theres some lightweight framework out there that can be a skeleton for me to organize CRUD functions, check for null values, handle MySQL errors, etc...
If not, a guide to developing a PHP mobile backend would be the next best thing.
Note: I apologize it there is a thread already asking this, but I couldn't find one that I thought fit.
Almost any of the major free frameworks would do the trick, Symfony for example handles regular page templating for your jQM pages and handles ajax nicely too.
However, if you only require the framework for the AJAX handling and something broader, you might be advised to develop your simple scripts, with less effort and less of a learning curve (of course, the learning may be part and parcel of your plan).
Another option is a Data Abstraction layer between your scripts and your PHP, this would give you greater flexibility in terms of your data changes, but not burden you with a hefty framework in between. Propel and Doctrine are worth a look and are often used as part of web frameworks.
I personally really like CodeIgniter, which is a very clean and powerfull lightweight PHP framework with easy database-access.
Just have a look at it.
Greetings,
Steffen
I am using a commercial PHP web application that stores information in a mysql database, and find myself needing to create some custom reports on that database information, ideally presented via the web with the ability of exporting the reports to PDF or some external format as well.
I could just slap together some PHP to query the DB and then show the results of SQL queries against that DB, but was hoping there may be a more intelligent framework I could employ to generate these reports faster and easier now as well as in the future. Codeigniter looks like it may be a good starting point, but I'm not in love with it. What do people use when they need to work with an existing SQL db info but dont want to roll it all from scratch?
edit - I know php/python/ruby enough to operate, but I'm rusty so starting from scratch will make the process longer than it probably needs to be. I'm looking to leverage quality frameworks if they exist to give me the best results in the longrun
I would recommend Django, it has a management command that can help automatically generate models from an existing database, inspectdb. You could leverage that to quickly get going and start using Django's powerful ORM to build your reports.
I'm writing a web application in Symfony for the first time, so I have a question regarding the use of Doctrine vs. Stored Procedures.
My background is in Java server-side, so I wanted to know what the pros and cons are for using stored procedures, versus using simple Doctrine code to get things done. At the most basic level, let's say that my Symfony web application is used for management, while there's another engine (which might or might not be written as a Symfony component, or indeed not in PHP at all) which retrieves configurations from the database for distribution or whatnot. Here I can see where stored procedures might be handy: both code bases use them to query and access data, while neither are preoccupied with the actual schema. If there's a change to the schema (adding a column in some table, for instance), then I'd only have to change the SRPOC, and nothing else, whereas if I had been using code in both engines to access data, I'd have to change them both to match the new schema.
Any comments? Or did I take it too far?
Thanks!
-DBG
If you don't use doctrine, you loose database abstraction, and object mapping. And this is a major loss. If you need third party apps integrations, you shouldn't let them interact with your database. Rather, provide a web service for them to read/write data via JSON, for example. This way you can change your database schema and have control over third-party apps.
Looking to develop a web service (api) in PHP to offer customers an easier way to integrate with our platform. There are workflow calls that will be validated with user/pass as well as some reporting options.
Sorry I can't post more details or code on the subject and I have never developed a web service but have had experience in using them via SOAP.
Now I would also need to offer a state or status of the workflow and I think REST would be the best choice here, but still looking for opinions on that.
For reporting I would like to offer different options such as XML,Excel/CSV any reason I would pick one over the other?
What are some of the pitfalls I should lookout for?
What are some gems anyone could offer.
Thanks in advance to any help as this is very important for me to understand.
UPDATE #1:
What would be the most secure method?
What is the most flexible method
(Platform independent)
UPDATE #2:
a little bit about the data flow.
Each user has creds to use the API and no data is shared between users. Usage is submit a request, the request is processed and a return is given. no updates. (Think Google) a search request is made and results are given, but in my case only one result is given.
Don't know if this is needed so it's an FYI.
Always handle errors and exceptions.
Problems will always make their presence felt in the application/api. Either at start or through further development. Don't leave this as an end task, and make it clear when an error occurs, with well documented response messages.
Also if your service will handle many requests, and for the same resource id (independent from user) the same resource is returned be sure to cache the information. And this not only for performance reasons, but for the cases when errors stuck up. This ways you can at least serve something to the client (possibly useful, more context required to be explicit).
The biggest and most important item I can offer is to guarantee your infrastructure behind the WS or at least what you are serving up via the WS is stateless. The moment you deviate form this it will become a nightmare and you will begin having to shoehorn code in to protect your data from getting fouled up.
An example would be a two clients making changes to data via the WS, ie...save configuration. How you deal with that on the back end makes things interesting. If your data is only heading outbound, you are in a much better situation then if you have to support pushing data into the back end.
Also, think out the API's in depth as with any public facing API. The moment you have a version out in the wild and then decide that API needs changed or deprecated begins to cause problems for the client base making use of your WS.
I am currently working on a web application that includes a web service (or 2 in ASP.NET MVC) and I highly recommend looking at the principles behind Service Oriented Architecture (SOA) as what I have found is that the most important aspect is to get the design of the web service API correct as that will effect the rest of your back end and either make your life easier or have you running into walls out of frustration.
Essentially SOA means design the web service around business processes, i.e. how the people who use your API are likely to use it.
A Good desgin is always a good idea, so I highly recommend you do a lot of reading on Web Sevice Design Principles before you start coding and save yourself or some other unlucky sod alot of grief latter on.
Also make sure that your design is agile as it will change frequently as communication between your company and your clients happens.
A little bit more related to implementation than design:
I would decide that the output of the service to be XML - this can be very easy parsed, by all decent languages. Also, if some client need other output, you could transform those XMLs through some XSLT processors and offer "other" web services, that outputs JSON, or whatever else they need.
Regarding the reporting, that depends on how the reports will be used - if the clients process them and they need only the data from the reports - then again suggest XML. In my opinion working with CSV is harder because you have to take in consideration all kind of special cases like "what happen if my data contains the separator field", "will the client be able to specify the separator", "how will I represent nested data", or all of these are straight forward with XML.
If your client needs reports to use them out of the box you could use BIRT -beautiful and free
Offering multiple outputs like JSON, CSV, YAML or XML is good - that gives the end user confort, at a very small cost! Dumping data is always easier than processing, and say that they already parse JSON for some reason - it is much easier to just hook that up for your API than implementing, say an XML-parser. Nowadays I see XML-parsers everywhere, so that should probably not be a problem, but I like the more "air-ish" nature of JSON; I have looked a little into YAML but never used it - but it looks promising, I'll definitively use that for the config files of my next project.
On the security side of anything that dynamically processes any input an user gives, one should treat such input like something you would not poke on even with a stick.
IMHO stateless REST is better than SOAP because it is less overhead, one can easily communicate with a REST-api by hand using curl or wget from the terminal. Jump-start so to say.
I would reccomend you to take a deep breath, a pencil & a paper, sit and sketch down everything that is going to be needed. Then you remove the less important stuff, and take a new paper and start to organize it. You can add the less important stuff in the next version of the API.
Try to design the API so that you don't lock yourself into a corner, make no assumptions on where it is going to head next.