As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm building my own Ajax website, and I'm contemplating between REST and RPC.
If my server supported Servlets I'd just install persevere and end the problem, but my server doesn't support Servlets.
RPC is simpler to code (IMO) and can be written in PHP easily. All I need is a database query executer. I'm using the Dojo Toolkit and JSON.
Why should I choose REST over RPC or RPC over REST?
The best way to understand it is to read Roy T. Fielding's dissertation on it, or relevant articles on his blog where he discusses the differences between pure REST and simply RPC architectures.
Another thing to note is that the Wikipedia article on REST is in dismal condition and Fielding himself, the 'inventor' of REST, suggests that the article is inaccurate.
The biggest thing people miss with REST is discoverability - resources should include URIs for other related resources inside their hypertext, instead of relying on URI naming conventions, which are out-of-band and non-standardized.
A big problem with popular RPC implementations like SOAP or XML-RPC is that they use HTTP underneath their own proprietary architecture, rather than taking advantage of all the different properties of HTTP like PUT, GET, DELETE etc. So this doesn't fit the traditional web stack as well - a cache server in the middle doesn't work, for example, without knowing about the meaning of the contents of the RPC call.
This is an incomplete introduction to REST and RPC but I think I've highlighted some of the important points that are often missed. Be careful, since there is a LOT of wrong information out there on REST.
That said, REST is not for everything. It's an architecture, so it's rather flexible how you can implement it. But if it doesn't make sense to access things primarily as resources, then REST may not fit, or it may only fit for parts of your application, which is fine.
Uhm ... to put it simple, both are very abstract models ... so abstract, they naturally occur everywhere...
REST is the idea of having resources addressed with a global identifier (the URI in the case of HTTP) that are accessed in a CRUD way (using POST, GET, PUT and DELETE in the case of HTTP ... well, at least that's the idea)...
RPC is the idea where you call a procedure on a different machine, passing in some parameters, and taking a return value...
There is a nice short comparison on Wikipedia
Persevere creates a service, that allows both (in a very elegant way, admittedly) ... it is RESTful (although it does not only use HTTP-features to achieve this) and exposes an RPC interface...
In the end, you should look at what your application needs to do ... as most people, you'll probably wind up with an RPC API (be it based on XML or JSON or whatever), that includes a transport layer for a partially RESTful subsystem ... this is, because having RESTfulnes, means flexibility ... if the client can more or less freely traverse the data on the server (through a set of simple CRUD methods), it does not depend on a limited (problem-specific) set of methods exposed through the API, and you can shift logic clientwards...
There are three different styles of services:
RPC API - the client sends a procedure and parameters to service and the service is responsible for the executing of the command and returning a result.
Message API (Document API) - the client sends DOMs (elements), which normally are more complex structures than RPC API calls, because they tend to do not imply operations directly.
Resource API - is used for accessing resources (database tuples, files, images and etc.). In general it should also provide good Media Type Negotiation.
SOAP and REST are compilation of standards from W3C, and the main difference is that SOAP uses HTTP, SMTP and etc. as transport protocols and REST uses it as application protocol, AKA it should support (GET, PUT, PUSH, DELETE, and POST). SOAP also implies using XML and REST could use any data type (JSON, XML, HTTP, etc.). Furthermore, one of the main advantages of SOAP is the Service Descriptor (WSDL file), which gives the possibility of auto-generation of Service Connector (proxy) to the client.
There is not a silver bullet; the type and architecture of a web service are dependent on the actual client and technology requirements.
For a general idea on the subject, see one of the Martin Fowler signature books - Service Design Patterns
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
AngularJS is very powerful when it comes to interactive HTML5 and model binding. On the other hand, PHP frameworks like Yii enable quick, well-structured, safe and powerful web application development. Both technologies provide sophisticated means for data access, iteration and page layouting.
Is it good or bad practice to mix those two approaches (client-side and server-side "page setup") or is this rather against the meaning of interactive, seamless HTML5 AJAX web applications?
I am not talking about generating JS using PHP (See this question) - I'm talking about generating a view that will make use of AngularJS.
I also know that an AngularJS page should (or can) communicate with the server via REST services to get data (See this question) instead of retrieving it from for example PHP variables directly. But to me it seems more convenient to design the "frame" for the entire web application separately in PHP (e.g. build the main menu or handle authorization/ sessions etc.)
It seems you may be more comfortable with developing in PHP you let this hold you back from utilizing the full potential with web applications.
It is indeed possible to have PHP render partials and whole views, but I would not recommend it.
To fully utilize the possibilities of HTML and javascript to make a web application, that is, a web page that acts more like an application and relies heavily on client side rendering, you should consider letting the client maintain all responsibility of managing state and presentation. This will be easier to maintain, and will be more user friendly.
I would recommend you to get more comfortable thinking in a more API centric approach. Rather than having PHP output a pre-rendered view, and use angular for mere DOM manipulation, you should consider having the PHP backend output the data that should be acted upon RESTFully, and have Angular present it.
Using PHP to render the view:
/user/account
if($loggedIn)
{
echo "<p>Logged in as ".$user."</p>";
}
else
{
echo "Please log in.";
}
How the same problem can be solved with an API centric approach by outputting JSON like this:
api/auth/
{
authorized:true,
user: {
username: 'Joe',
securityToken: 'secret'
}
}
and in Angular you could do a get, and handle the response client side.
$http.post("http://example.com/api/auth", {})
.success(function(data) {
$scope.isLoggedIn = data.authorized;
});
To blend both client side and server side the way you proposed may be fit for smaller projects where maintainance is not important and you are the single author, but I lean more towards the API centric way as this will be more correct separation of conserns and will be easier to maintain.
What's the difference between a REST system and a system that is RESTful?
From a few things I've read most so called REST services are actually RESTful services. So what is the difference between the two.
Representational state transfer (REST) is a style of software architecture. As described in a dissertation by Roy Fielding, REST is an "architectural style" that basically exploits the existing technology and protocols of the Web.
RESTful is typically used to refer to web services implementing such an architecture.
REST based Services/Architecture vs. RESTFUL Services/Architecture
To differentiate or compare these 2, you should know what REST is.
REST (REpresentational State Transfer) is basically an architectural style of development having some principles:
It should be stateless
It should access all the resources from the server using only URI
It does not have inbuilt encryption
It does not have session
It uses one and only one protocol - HTTP
For performing CRUD operations, it should use HTTP verbs such as get, post, put and delete
It should return the result only in the form of JSON or XML, atom, OData etc. (lightweight data )
REST based services follow some of the above principles and not all
RESTFUL services means it follows all the above principles.
It is similar to the concept of:
Object oriented languages support all the OOP concepts, examples: C++, C#
Object-based languages support some of the OOP features, examples: JavaScript, VB
Example:
ASP Dot NET MVC 4 is REST-Based while Microsoft WEB API is RESTFul.
MVC supports only some of the above REST principles whereas WEB API supports all the above REST Principles.
MVC only supports the following from the REST API
We can access the resource using URI
It supports the HTTP verb to access the resource from server
It can return the results in the form of JSON, XML, that is the HTTPResponse.
However, at the same time in MVC
We can use the session
We can make it stateful
We can return video or image from the controller action method which basically violates the REST principles
That is why MVC is REST-Based whereas WEB API supports all the above principles and is RESTFul.
"REST" is an architectural paradigm. "RESTful" describes using that paradigm.
As Jason said in the comments, RESTful is just used as an adjective describing something that respects the REST constraints.
REST stands for representational state transfer. That means that state itself is not transferred but a mere representation of it is. The most common example is a pure HTML server based app (no javascript). The browser knows nothing about the application itself but through links and resources, the server is able transfer the state of the application to the browser. Where a button would normally change a state variable (e.g. page open) in a regular windows application, in the browser you have a link that represents such a state change.
The idea is to use hypermedia. And perhaps to create new hypermedia types. Potentially we can expand the browser with javascript/AJAX and create new custom hypermedia types. And we would have a true REST application.
This is my short version of what REST stands for, the problem is that it is hard to implement. I personally say RESTful, when I want to make reference to the REST principles but I know I am not really implementing the whole concept of REST. We don't really say SOAPful, because you either use SOAP or not. I think most people don't do REST the way it was envisioned by it's creator Roy Fielding, we actually implement RESTful or RESTlike architectures. You can see his dissertation, and you will find the REST acronym but not the word RESTful.
REST is an style of software architecture for distributed software
Conforming to the REST constraints is referred to as being ‘RESTful’.
Very used today to build web services as an alternative to SOAP.
Here you have some links to check
http://en.wikipedia.org/wiki/Representational_State_Transfer
http://www.computerworld.com/s/article/297424/Representational_State_Transfer_REST_
http://www.ibm.com/developerworks/webservices/library/ws-restful/
thanks for the answers.
Read this article by Alex Rodriguez which suggests that a RESTful web service has 4 basic characteristics which are:
Use HTTP methods explicitly.
Be stateless.
Expose directory structure-like URIs.
Transfer XML, JavaScript Object Notation (JSON), or both.
Representational State Transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. The term Representational State Transfer was introduced and defined in 2000 by Roy Fielding1[2] in his doctoral dissertation. Fielding is one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification versions 1.0 and 1.1.
Conforming to the REST constraints is referred to as being ‘RESTful’. Source:Wikipedia
Web services are essentially web sites whose content is consumed by computer programs, not people. REST is a set of architectural principles that stipulate that web services should maximally leverage HTTP and other web standards, so that programs gain all the good stuff that people already can get out of the web. REST is often contrasted with SOAP web services, and other "remote procedure call" oriented web services.
Stefan Tilkov's presentations on REST at Parleys.com are quite good, especially this one.
For a book, you can't get any better than Richardson and Ruby's Restful Web Services.
A service based on REST is called a "RESTful service".
Source I rely on posting that: Dr.Dobbs Archive
There are 4 levels of API defined in the Richardson Maturity Model. These are defined as:
level 0: any system that has a single endpoint for all its apis(SOAP or RPC fall in this category). Level 0 apis can also resemble "commands".
level 1: a ResourceUri described system. This is a system that defines multiple entity-based URIs (instead of having a single endpoint like a level 0 systems would). These URIs can use different http actions (POST, GET, PUT, etc) to implement different actions against that resource.
level 2: aka level 1 w/ a compliant use of Standard HTTP methods/verbs and multi status code responses
level 3: aka level 2 plus HATEOAS (hypermedia included in the response which describes additional calls you can make)
While levels 1, level 2, and level 3 can be considered as REST systems, only the stricter levels (aka level 2 and level 3) are considered to be RESTful.
So essentially all RESTful apis are REST apis, but not all REST apis are RESTful
definition of the Richardson Maturity Model
Coming at it from the perspective of an object oriented programming mindset, REST is analogous to the interface to be implemented, and a RESTfull service is analogous to the actual implementation of the REST "interface".
REST just defines a set of rules that says what it is to be a REST api, and a RESTfull service follows those rules.
Allot of answers above already laid out most of those rules, but I know one of the big things that is required, and in my experience often overlooked, as that a true REST api has to be hyperlink driven, in addition to all of the HTTP PUT, POST, GET, DELETE jazz.
A "REST service" and a "RESTful service" are one and the same.
A RESTful system is any system that follows the REST conventions as defined in the original document that created the idea of RESTful networked applications.
It's worth noting there are varying levels of RESTfulness. Overall, REST is a style, not a standard, so there is room for interpretation based on needs. one example is hierarchical resource URLs (e.g. /things/ID/relatedthings) vs flat URLs (e.g. /things/ID and /relatedthings?thing=ID)
Think of REST as an architectural "class" while RESTful is the well known "instance" of that class.
Please mind the ""; we are not dealing with "real" programming objects here.
REST(REpresentation State Transfer) is an architecture using which WebServices are created.
and
RESTful is way of writing services using the REST architectures. RESTful services exposes the resources to identify the targets to interact with clients.
REST is an architectural pattern for creating web services. A RESTful service is one that implements that pattern.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
( Not a duplicate of Should i use rest or soap. That question has only 1 answer which doesnt provide many arguments except overhead ).
Before marking this question as a duplicate, consider that I am looking for answers from people that made the choice before me and that explain their reasons based on their own experience. Answers that simply state "overhead" or "more complex" do not fit that profile.
Now for the question:
A while back I've started to setup a new api using Soap (PHP / Zend_Soap_Server, Zend_Soap_Autodiscover). Although I've figured out how to work with soap, the complexity makes me wonder if this is a good choice for future maintenance.
I've heard about REST, but do not have any experience with it.
So the question is: what are the pro/cons of REST vs SOAP and what is your suggestion when creating a fresh new api (rather complex api, several dozens of methods, using ssl, must have decent security etc), REST or SOAP.
If you think your answer hangs in the balance between REST and SOAP and a specific dependency or feature would tip the scale, be sure to ask whatever you need to know. I'll answer as soon as I can.
A short list of the api's features:
Authentication
Perform math functions for a frontend
Provide binary files to the frontend (invoices)
Basic CRUD of various sorts of information
The place of the api is basically as follows:
Internet -> website -> [internal network] -> API/Backend -> Database
Thank you for your time in advance..
This is of course a very controversial topic, but at the same time, most new services are REST for a number of reasons. I won't cover the differences between the two (as that is well documented) but more the reasons I think you'd build a new service, today (2012) using REST:
REST is much simpler, basically just building on top of HTTP
You can test (and debug) REST services using a web browser or something like curl or httpie. Yes this is technically possible with SOAP as well, but you have to somewhat understand the SOAP schema.
Similarly, you can build a REST client as long as you have a way to access HTTP. SOAP requires a SOAP-capable library
REST is more of a style and builds on top of HTTP, whereas SOAP is an entire protocol on top of HTTP (which is also a protocol)
SOAP ends up with crazy extension protocols like WS-Security, WS-Encryption (which, essentially, are incredibly complex designed-by-committee solutions to problems the rest of the internet solved for HTTP a couple decades ago)
If you look around at some of the major APIs on the internet (eg Google, Facebook, Twitter, etc) you'll find a lot of REST, and little to no SOAP. Those that do have SOAP interfaces are deprecating or dropping them completely, because there's very little reason to stick with it any more.
In fact, many of the big services are going a step further and only offering their REST services with JSON formatting, as opposed to XML or both, because like REST over SOAP, JSON has a lot of advantages in terms of size and simplicity over XML that it doesn't make much sense to continue supporting XML.
There are also almost no drawbacks to REST compared to SOAP.
About the only practical consideration I can think of is from a client perspective. With SOAP (because of WSDL, assuming you produce one) you can point a SOAP-capable IDE at the service (such as VisualStudio) and it will generate a native client proxy API based on the remote service. This is somewhat nice in terms of getting up and running quickly, but has its own set of drawbacks: it forces you to use the objects defined in the service (whereas with REST, you can use your own object definitions as long as the data maps in), and depending on how the remote service handles versioning (or not) and how you use it, you may end up having to update major chunks of your app because of something as simple as a naming change.
From the server perspective, I really can't see any technical benefits to choosing SOAP over REST whatsoever.
TL;DR: SOAP is not necessarily bad, it's just that REST is better.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
It seems the more popular frameworks use a front controller. I understand the benefits of a front controller (reduces redundancy and simplifies extensibility), but
I want to know what PHP frameworks do NOT use a front controller. Additionally I am interested in those frameworks that use page controllers and that recommend using a real file directory structure for the urls as opposed to rewriting almost every url or using a mess of a query string. Additionally I am interested in knowing which of the frameworks that do not use a front controller implement MVC. Lastly, any additional details you can provide on the non-front-controller frameworks would be useful, particularly what version of PHP it uses or requires. (I know I can get this later information from other sites so it is not as important.)
Consider the words of Rasmus Lerdorf (the original creator of PHP):
"As for MVC, if you use it carefully, it can be useful in a web
application. Just make sure you avoid the temptation of creating a
single monolithic controller. A web application by its very nature is
a series of small discrete requests. If you send all of your requests
through a single controller on a single machine you have just defeated
this very important architecture. Discreteness gives you scalability
and modularity. You can break large problems up into a series of very
small and modular solutions and you can deploy these across as many
servers as you like. You need to tie them together to some extent most
likely through some backend datastore, but keep them as separate as
possible. This means you want your views and controllers very close to
each other and you want to keep your controllers as small as possible." - Rasmus Lerdorf
UPDATE: Many thanks to user Alex for the first of hopefully more answers. His answer is QCubed ..
"remember that front controller (index.php) and MVC are separate
patterns. That is, you can have an MVC framework that does NOT
implement or require the front controller. My framework of choice,
QCubed, happens to be like that." - Alex
Now if we can reopen this question then we can continue what we started and put together a list of frameworks that do not use a front controller. Please vote to reopen. Thank you.
I'm still learning Symfony2, so if I'm not wrong, i think you can have different front controllers. And the code would be separated in different Bundles.
By default, it has two fron controllers, one for production and the other one for development. However i think you can create more than one (one for each page)
Hope this helps
Interesting question, although I am not sure what your end game is. A controller basically 'bootstraps' the framework into a useable state. My experience lies with Symfony, Zend, and CakePHP, and can tell you that the controllers used in Symfony are quite short (~50 lines of code). However the underlying code is quite extensive, but this code does a number of things such as setup your ORM, cache heavily used arrays (creating static files in /cache directory), and initialize an autoloader for file calls, just to name a few.
Within the Symfony Framework context you have a primary controller, but you also have mini-controllers, or as you put it, page controllers, these controllers are referred to as 'actions'. An action acts as a bridge between a user request and various attributes of your application which may include file/data stores, request handling, user redirects etc. As with the primary controller the actions are meant to be lightweight, mainly consisting of API calls to underlying classes and functions.
I have actually used Zend within Symfony to fill the gaps in functionality that Symfony does not provide. So to your question, I am using Zend functionality without any controller interaction. All I need to do is initialize Zend within the autoloader (b/c Zend is correctly namespaced). Also did this with CakePHP to take advantage of the Inflector class, no controller usage, just calls to functionality I didn't want to write myself.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have just "finished" coding up a relatively involved web service in PHP. The code base is now a bit of a mess due to last minute requests, changes, add-ons, the usual.
I tried to code it as lightly as possible and in a manner that would maximise performance.
Therefore, I didn't use any frameworks like Zend or any ORMs like Doctrine.
I was wondering if there are any frameworks or design patterns that exist for the sole purpose of building APIs/web services in PHP?
I'm thinking of a refactor and I want to make sure now I know exactly what's involved I can build this thing properly.
I apologize in advance for the self-reference here to my own framework - there's no way for me to help you otherwise since I don't use anything else. I'm not advertising, since it's not public.
As I said in my comment, I think a good web front-end framework shouldn't mean it is a poor web service framework.
Because I was unsatisfied with the restrictive way any of the popular PHP frameworks (CodeIgniter, CakePHP, Kohana) processed requests, as well as their size, I wrote a framework that is designed for really only two purposes, process a request and determine an action to take, and then separate the code for that action from the view (response).
The design pattern I use is this:
All URLs are rewritten (mod_rewrite) and passed to your execution entry point.
Your entry point sets up paths that it will recognize and process. I.E. for a web service:
/users - User list
/user/* - User identified by the value where * is.
/user/*/delete - Delete the user
/posts - List posts
/post/* - View post *
Along with the path you specify a function, I.E. UserActions::saveUser to be executed if the HTTP method is POST. The reason it's only executed on POST is to enable output and input to have the same URL.
The path also specifies a view. This is the response body that will be sent to the browser. It can be rendered as straight PHP, or you could plug in a template engine. In the case of web services, all paths would probably use a single view that renders your data in the output format (JSON, XML, whatever). The view can be just a PHP method and is not required to specify a template file.
In the case of a web front-end, the view can have a parent view which wraps it (creating the page from the inside-out).
The last point is security. You can define a security type to be applied to any path. A security type just specifies what function (like SecurityManager::authorize) to check for authorization and if false is returned, it redirects to a path of your choosing.
The reasons I believe this design pattern works well for Web Services:
Enables you to use a single-entry point, but can be used with multiple entry points (for optimization, if needed).
No assuming that you want your URLs to match your Object Model, like most of the major frameworks do (a notable exception being Zend, as mentioned in the comments).
Easily adapted to REST (instead of just checking for POST, check for other methods too).
The removal of any HTML feels completely natural, since in this pattern the response is completely separated from processing.
This can all be done in a few classes.
Imho, every MVC-based "thing" can really help you.
If you really do not want to use anything (give a try to CakePHP!) already existing, strucutring your code following mvc can really help you to split the logic of your application on more layer, and keep it more readable and debuggable.
Of course, also with the better pattern you can write awful code, it's up to you!
I think you can use the same patterns you use by simple web applications. A restful service has different interface than a web application, but everything under that interface is the same. You can transform a restful service to a web application like so:
METHOD host/resource/data => host/resource/METHOD?data
resource is the controller, METHOD is the action.
For example:
GET http://library.com/books/123 => http://library.com/books/get?123
So you can use front controller and MVC.
A quick Google and I see
Frapi
Cake
Meditation
Code Canyon
I have never used any of these