I'm trying to create a REST service which shows/adds/deletes/edits soccer data in a database.
I've made a design of how I could achieve this, but it becomes quite complicated.
For example, when a goal is scored, what URL should I call?
So the question is, am I going in the right direction or do you advice something way different?
I agree with Abhiniav's answer except on the fact that PUT should not always be used for editing. It should only be used when you are sending the new complete resource. If you are sending a modification or partial, use POST, or the lesser known PATCH.
Reading up on Safe and Idempotent methods should be useful.
You would most likely use POST or PATCH to update the goal count: /{country}/team/{team_id}/goals.
The biggest reason something isn't REST is because services are not discoverable. Read up on HATEOAS.
Everything seems fine in your structure except that you should switch PUT and POST.
PUT can be used for both updating/creating records. In case you know the resource ID before hand, you can use PUT.
POST is used when you would be creating new resources whose IDs you would not know.
Stackoverflow has a pretty detailed discussion here:
PUT vs POST in REST
Related
I found few posts on this subject, however I would like to know the best practice to accomplish the following scenario:
I am willing to make a call to a 3rd party web service, that I will provide in my call few parameters, being one of them a POST callback to my website. The response will send me a token, that I should utilize on my following service calls.
I could send them (for example) a callback URL like this:
http://www.example.com/response.php
However, I was wondering how could I use an URL hiding my php file, like this:
http://www.example.com/Response/
I found few articles mentioning redirect, but there are many options on that, and since I'm new to Wordpress, I was wondering if someone with experience on this could give me some advice to be on track to make it the right way.
Sorry if this question was answered before, but I honestly found dozens and dozens of similar requests, but none of them that I found was clear as a best practice.
Many thanks!
Update:
I forgot to mention couple things:
1. I am planning to create a plugin from this, so it should be something that should be configured programmatically, while installing the plugin.
2. The URL that will be called by the remote client, is not a page, just an URL that will resolve into the php file with my code.
I hope it makes sense.
Thanks!
I realize similar questions have been asked and answered, but bear with me because I haven't found the answers satisfactory in that, I still don't see how to solve my problem. I just understand "you shouldn't do that". Fine, but can someone help me understand how to accomplish this (seemingly) simple task?
I have a number of entities (i use that term loosely, these are not doctrine entities, they are simply from-scratch data models that load data from an external API). I would like some of these entities to have a getUrl() function, so that anywhere I encounter them, I can simply call $entity->getUrl() and have a proper and consistent url to use.
Initially I was constructing these url paths by hand, but then realized, "I should be using the urls defined in the routing configuration to generate these. Then they will REALLY be guaranteed to be consistent site-wide". So I search and come across these answers on SO that say "Your entities shouldn't know about anything but other entities" and "Create a separate service." Well, fine, but I still want an $entity->getUrl() method to call! Is it impossible to achieve this and still adhere to basic principles? Can someone explain to me how I can get it done? If I create a separate service, I still don't seem to be able to accomplish my goal, since "you shouldn't access services from inside entities."
What's a guy to do? Can anyone help me understand?
I have to use php,mysql to do a prroject.I have chosen to make a simple forum and use a lot of Ajax with it.since i am still a novice, can you guide me to a simple ajax guestbook which i can work on to make a forum? i want to end up with something like this but even simpler. http://board.fuzzylime.co.uk/
It's not terribly complex. Just set up a MySQL database, and use a PHP script to connect to it, check for a login, and add a record for a post or list records to view a post.
If you are just starting out, I would suggest that you first understand the basics of building a forum in PHP.
Personally I liked the forum example in this book . I thought it was explained very well. You can also just google for "PHP forum tutorial" to find a couple examples, like this one and this one.
Once you have the basic idea figured out you can start looking at how to make an AJAX style implementation. For that, you can also just google AJAX tutorials and go from there. Either way, I think if you are going to build a forum, its important to understand the basics behind building a forum before jumping into a more complicated example like an AJAX driven one. Understanding the PHP portion of the application, and the database behind the whole thing is a very important step.
I would like to know the best practice to use when listing items from a database in an ajax call with Zend Framework. The end result is to show notes concerning a customer in a css popup when clicking on a link.
I'm currently looking into using Zend_Json_Server, but I can't really see how I could implement it. Is Zend_Json_Server good to use in these cases - and if so, should I use it outside the MVC structure as some suggest?
Most importantly:
Could someone please give me an example of how it could look like?
From Calling the javascript function from the view to listing the items in the CSS div (popup).
This would help immensely and would be really interesting to know about!
KR
Josef
I have certainly seen commentary - I think by MWOP himself - that you want API service calls to be fast; if you are only returning JSON, for example, then you don't really need the full MVC. On the other hand, the context-switch action-helper is part of the MVC stack and is often used to handle AJAX calls. I guess idea is that if your AJAX call needs to perform much of the same processing as a standard MVC request, differing only in the return, then it might be DRY-er, albeit slower, to simply use the context-switch. If speed/performance is the issue, then perhaps a separate service might be warranted.
But I confess I have no experience here, so if I am just shooting crap, please feel free to correct me. ;-)
The MWOP link above contains some ideas for how to set up service endpoints.
I read a lot of Restful tutorials for PHP.
(I don't want to go in depth into why I am not using RoR. It is due to the team being more familiar with PHP)
Because we are planning for future expansion into having APIs i read that it is important to implement Restful web services.
I have looked at tutorials such as
http://www.gen-x-design.com/archives/create-a-rest-api-with-php/
Apparently restful is meant for webservices.
What about for webpages? can they be RESTFUL as well?
if the answer is NO, please do not go beyond this line AND just tell me. Thank you.
i know to make the urls look like RESTFUL urls is to simply use mod_rewrite. However, i am quite sure, restful architecture goes beyond just making the urls look nice.
For eg, i have a list of items on a webpage called list.php . Each item has a delete link next to it. E.g., list.php?id=1&deleteitem
What happens is that when someone clicks on the list.php?id=1&deleteitem link, of course i go back to the same list.php file and check for the param deleteitem in $_GET.
If detected, i will then delete from database based on the param id in $_GET.
After which i will redirect back to list.php WITHOUT any params.
I am wondering, how do i make this whole flow RESTFUL?
I am asking because in REST, to make delete something you need to use HTTP request method (DELETE).
Clearly in my links they are all just simply Delete
Please enlighten me.
My programming is not that strong and it would be good if the advice given can be as layman as possible.
Thank you.
EDIT
I have 2 follow up questions.
question 1) Since this is a list of items with paging, how would the URL look like if i want to make it RESTful?
question 2) Since i am putting DELETE links next to every one of the items in the list, I understand now, i should use
<form method="POST">
<input type=hidden name="_method" value="delete">
<input type="submit" >
</form>
instead.
however the form should be posted to where? the item url? /items/{item-id}
But i want to go back to this listing page displaying a success message AFTER successfully deleting the row in database.
I also want to avoid a popup message when i refresh this listing page with success message.
If i post back to this list.php url, then it is not RESTful yes? because i am told by the answers below that each item is a resource which needs its own url.
Please enlighten me. Thank you.
RESTful is commonly used when referring to web services, but it can very well apply to web pages. In a nutshell, being RESTful is about dealing with resources. A resource can be a person, a book, a movie, a theatre, a ticket, or whatever you fancy.
There are four basic operations you could perform on a resource.
create (POST)
read (GET)
update (PUT)
delete (DELETE)
Most web browsers do not support the PUT and DELETE actions, so you can only use POST actions for sending data. Rails fakes PUT and DELETE by passing in a hidden parameter named _method that the framework picks up and routes it depending on that value.
Also, you should never use GET for any destructive action. Any action that changes the state of your resource(s), should be called with either POST, PUT, or DELETE depending on the change (fake PUT/DELETE with POST if need be).
I would suggest you checkout the way RESTful routing is handled in Rails just to get an idea, if nothing else. Althought the four actions above are sufficient to modify a resource in any way possible, Rails also introduces three other types of actions that sound useful.
index (listing view of all items)
new (usually a form view to add a new
resource)
edit (usually a form view to
update an existing resource)
Pretty URL's is definitely on the table when designing RESTful sites, but probably the biggest win is that the quality of code improves automatically. When you're only dealing with resources, and there are only four potential actions that can be applied to a resource, then things start to clean up by themselves.
Edit 1:
Self-descriptive URL's are preferred and will make your life easier, but there's nothing stopping from creating cryptic URLs that uniquely identify a resource and manage it using the HTTP verbs. URLs such as the ones below (using md5) to uniquely identify resources are perfectly RESTful.
// represents a person "John Doe"
http://example.com/4c2a904bafba06591225113ad17b5cec
// represents the movie "Lord of the Rings: The Two Towers"
http://example.com/1d9198260dec7bda3fb21e232d60fec3
// represents the "Formula One" sport
http://example.com/fs340as?id=23xa12&type=SP012Ts
That's REpresentational State Transfer right there. The MD5 hash is like the mailing address of the resource that remains constant. The representation could be the movie's details (in html/xml/json/etc.), or maybe the video of the movie itself depending on the capabilities of the client).
Edit 2:
Let's say you have a resource which is a collection - countries of the world.
It could be represented by a URI and HTTP verb such as:
GET /countries
Since paging is a property of the application rather than the resource itself, you could supply querystring parameters to control it.
GET /countries?page=1
A country is also a resource that is a part of the countries resource. You could identify a country with a URL such as:
/countries/<id>
And operations on this country could be performed with these verbs:
GET /countries/<id>
POST /countries -- the new country has no existing representation
PUT /countries/<id>
DELETE /countries/<id>
Long answer short: yes. REST is for both. That's because even if you have the simplest of all websites one would still have to GET your page and maybe POST ones personal data to add an entry to the guestbook. In that we all adhere to REST somehow.
In your case poor browser implementation makes it hard to implement a PURE RESTful way. DELETE isn't supported without Javascript and therefore you would have to use GET or POST (which both do have a totally different meaning from DELETE in REST) anyway.
Restful approach can surely be used in web pages as well. Putting commands in an URL is not a good idea, due to the side effects you are mentioning. When you change the database (or do whatever that changes the model), use POST commands.
Of course, you don't have PUT and DELTE in major web browsers, but you can always send a simple POST with some specific parameter like method = "PUT", method="DELETE" etc.
I wrote a tiny framework on top of Zend Framework to make implementing RESTful interfaces easier:
http://github.com/mikekelly/Resauce
You can use that for web services and websites. Essentially, a website is just a web service driven by HTML.
RESTful means not "beautiful URIs". Despite the fact that URIs identify a resource the only thing REST says about URIs is, that they shouldn't contain an action paramater like "delete".
In your case you would call
DELETE /items/6793
The Answer would be typically status code 200 OK with the modified list as message body. See: http://restpatterns.org/HTTP_Methods/DELETE
Since HTML 4 doesn't support other form actions than GET and POST you have to workaround with a hidden paramater and override the HTTP method on the server side.