I'm looking for some thin layer on top of handling HTTP requests that can easily do routing to different backends, based on the uri / rest verb / actual service location / .... This layer should also handle encoding into whatever the requested format is (xml / json / returning binary data / etc.).
The most important point though is to make it pluggable into some backend - whether it's a message queue, job dispatcher, external process, or something completely different. They should be handled with minimal wrapper for the needed message translation.
So basically, that would be a customisable request dispatcher with some magic on top. Does something like that exist as a separate application now?
Edit: Almost forgot - it would be great if it was written in PHP... but if something else matches the description, I'd have a look too.
Don't know about PHP, but if Java and/or Python are acceptable options for you, you should take a look at RESTx, which was designed for the simple and fast creation of RESTful services. RESTx is fully open source, GPLv3 licensed.
I agree that many frameworks are all about object creation and mapping, which often can be very annoying and get in the way. RESTx, however, is about the data, the automatic conversion of content types and so on. With RESTx you can write custom components in either Java or Python. These components can take care of access to databases, custom APIs, legacy data, cloud services, etc. RESTx examines the code and automatically produces a self documented, discoverable, RESTful API. It's all links you can follow. Take a look at how to take a tour of the server with a web browser.
The key is that you can POST parameter sets to those components which are then stored and accessible under a new URI. You access the URI, the parameters get applied to the component and you get the output back. Thus, you can rapidly create new RESTful web services and resources. You can access other resources easily from within your component's code and it doesn't cause an additional HTTP request.
I'm the lead developer for RESTx, so if you have any questions about it, please contact me on the forums (links to those are on our web site).
Zed Shaw of Mongrel fame is attempting to do just this. He's creating Mongrel2 (still in development), essentially a universal frontend for web application backends. It allows you to plug in any program that can send and receive 0MQ or HTTP messages like a reverse proxy.
It also uses a sane configuration file system: SQLite. No more messing around with Apache config files with weird syntax.
It's written in C, so it may not be as easy to deploy as a language like PHP, but it certainly scales very well.
If you're not satisfied with Mongrel2, it's relatively easy to roll your own. I've used nodejitsu's node-http-proxy for one of my own projects. It's simple and fast. Plus, you can write your routing rules using regular old if statements.
I'm new to StackOverflow so it won't let me embed more than one hyperlink, haha.
Related
background
last month I designed my first REST API as my effort to learn php, it was a chat messenger, to provide access to different APIs I relied on the folder and file structure, i.e. the URL was pointing to a actual file in server path and that file was a complete script to do it's job, so all that the app using API had to do was to call the specific URL and provide proper input,
Question
Lately, I read about Routers, and this question came to my mind, Why should I use routers and do I really need them?
my points so far:
_Without using Routers the API design and access is easy, the Apache handles the routing(If I am not wrong).
_With routers code is more complex however I can have some code running without the actual script being engaged, so I have more control over API access and such.
While Yassine has pointed out an answer elsewhere which contains a lot of information, it is a bit misleading (and wrong) in some regards.
A router is commonly used as part of a front controller architecture pattern. This funnels all incoming requests to a specific handler which will normally then pass the request on to a specific bit of functionality via the router.
The advantage of doing this is that it avoids duplication of code - specifically to handle things like session management, authentication, authorization, and templating.
Consider, for example:
<?php
$sitedown=$_SERVER['DOCUMENT_ROOT'] . "/sitedown.php";
if (file_exists($sitedown)) {
require_once($sitedown);
exit;
}
require_once("session/use_memcache_sessions.inc");
require_once("session/authorization.inc");
require_once("router.inc");
require_once("template/pagelayout.inc");
session_start();
begin_page_template($_SESSION['user_prefs']);
if (is_authorized($_SERVER['PHP_SELF'], $_SESSION['user_groups'])) {
route_request($_SERVER['PHP_SELF']);
} else {
show_unauth_message();
}
end_page_template();
While you could just drop lots of self-contained scripts onto your filesystem, with each one acting as an entry point, each of them would need to implement the logic above. If you decided to start using redis for your session management, or change the templating, you would need to change each script to accomodate the new behaviour.
I'm planning a small web application project which will consist of both a website (using PHP) and in the future a mobile application. I want to implement a RESTful API (using PHP) to communicate with the mobile app. But since the API and the website will both be written in PHP and hosted on the same server, it seems a bit odd to make HTTP calls from the website to the public API (or isn't it)?
Anyway, I am considering putting a layer between the API and the business logic, basically just consisting of an object that exposes the same API as the public RESTful API, but as a PHP object that can be accessed directly from the website.
Is this a good or bad idea? Why?
Is this a well known pattern? If so, what is it called?
I found some sites proposing a similar structure and calling it "API Gateway Object", but I'm not sure if that is an actual well-known pattern or just something they came up with tho.
Here's a sketch of what I have in mind:
Good question (answer) ... not sure it is the right kind for this site. I use exactly that pattern, which I ended up rolling out after hard-fought battles with other architectural approaches/frameworks i.e. I dont know its name.
some pros :
Turns out it is also extremely useful for testing, climbing up the abstraction ladder can be easily structured and exercised with your favorite testing toys.
Your mobile data architecture can be a straight isomorph of the Gateway Object model.
It nicely decouples for straight php access AND it still permits you to keep some things in play when it matters : auth, logging, traceability of database access.
It future proofs your design : although it may seem silly at the moment, you may find that you will eventually need to have www and mobile presentations served from different instances. Migrating your php presentation to use RESTful API will be a cinch if you do this right.
An example : Say I have a Message object, this object will have a number of 'normal' classes:
Message : the plain-old-php-object, no side effects, no persistence
MessageDAO : the persistence manager for Message. basic CRUD, no business logic, just elementary CRUD
MessageWF : the workflows offered by the business logic
IBMessageSpec : a specification for a message
OBMessage : the representation of the message that I wish to send to the caller
I use a DI container to inject in each of the above the specifics of the context.
In my Mobile , I have OBMessageSpec wihch is essentially an IBMessageSpec, and IBMessage which maps the servers's OBMessage. That code is pretty much re-useable to multiple instance types, and apps.
It is OK idea. You could provide an API for internal PHP usage via some API Gateway Object and expose RESTful API, that uses same API Gateway Object. It may be named Adapter, because it adapts your php API to be used by external services via HTTP.
But why do you need something to be known pattern to use it ? It perfectly lays on your needs, this architecture allows you to keep your modules consistent and avoid duplications of logic.
You can use RESTful on PHP side, it would be slower, but more flexible - maybe in future you'll need to rewrite backend with some other language - you don't need to change frontend!
So, it is up to you to decide, what is more preferable for you, it is not about patterns.
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.
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.
I have been in web programming for 2 years (Self taught - a biology researcher by profession). I designed a small wiki with needed functionalities and a scientific RTE - ofcourse lot is expected. I used mootools framework
and AJAX extensively.
I was always curious when ever I saw the query strings passed from URL. Long encrypted query string directly getting passed to the server. Especially Google's design is such. I think this is the start of providing a Web Service to a client - I guess.
Now, my question is : is this a special, highly professional, efficient / advanced web design technique to communicate queries via the URL ?
I always felt that direct URL based communication is faster. I tried my bit and could send a query through the URL directly. here is the link: http://sgwiki.sdsc.edu/getSGMPage.php?8
By this , the client can directly link to the desired page instead of searching and / or can automate. There are many possibilities.
The next request: Can I be pointed to such technique of web programming?
oops: I am sorry, If I have not been able to convey my request clearly.
Prasad.
I think this is the start of providing
a Web Service to a client - I guess.
No not really, although it can be. Its used to have a central entry point to the entire application. Its a common practice and has all kinds of benefits, but its obviously not required. Often thes days though even a normal url you see may not actual be a physical page in the application.. each part of the path may actuall be mapped to a variable through rewriting and routing on the server side. For example the URL of this question:
http://stackoverflow.com/questions/2557535/general-web-programming-designing-question
Might map to something like
http://stackoverflow.com/index.php?module=questions&action=view&question=2557535&title=general-web-programming-designing-question
is this a special, highly
professional, efficient / advanced web
design technique to communicate
queries via the URL ?
Having a centralized page through which all functions within an application are accessed is part of the Front Controller Pattern - a common pattern in applications generally used as part of the overall Model, View, Controller (MVC) pattern. In MVC, the concerns of the application are divided into the model which holds the business logic. These models are then used by the controller to perform a set of tasks which can produce output. This output is then rendered to the client (browser, window manager, etc..) via the view layer.
I think that essentially what you are asking about is query strings. In a url after a page, there may be a question mark after which, there may be URL parameters (generally called GET request parameters.)
http://www.google.com/search?q=URL+parameter
Generally, processing this would be done on the server-side. For example, in PHP, one could use the following:
$_GET['q']
The aforementioned code would be the value of the variable. Alternatively, to do this client-side, one could use anchors. Replace the question mark with a hash sign #
Since this is used for anchors, when a URL is changed to have an anchor tag, the page is not refreshed. This allows for a completely AJAX-driven page to manipulate the URL without refreshing. This method is often used also for enabling back-button support for AJAX pages.
In JavaScript, one can use the onload handler as an opportunity to read the URL of the page and get the hash part of the URL. The page could then make a request back to the server to read any neccessary data.
It's a consequence of using a front controller architecture. This fits neatly with the idea of a wiki where the same code is used to render multiple different wiki pages - the content is defined by the data.
Using the query part of the URL for the page selection criteria is not the only solution. e.g. if you are using apache then you could implement:
http://sgwiki.sdsc.edu/getSGMPage.php?8
as
http://sgwiki.sdsc.edu/getSGMPage.php/8
(you'll need to add your own parsing to get the value out.
Alternatively, you can use mod_rewrite to map components out of the path back into the query.
There's no particular functional/performance reason for adopting any of these strategies. Although it is recommended, where the URL is idempotent, that each page be addressable via a GET operation (also useful for SEO).
C.