What should be the standard approach for getting user information after login ?
POST request to validate user/password and retrieve information on response
POST request to validate user/password followed by GET request to retrieve information?
As far as I understand, GET should be the preferred one to retrieve data, but it seems burdensome to performe two requests; at the same time, it feels weird to get data back on POST response. Which should be preferred?
My 2 cents:) if you really want to follow REST Paradigm then you should use standard http method as GET. Although an overloaded POST might do the job however it’s not following the standard.
In SOAP world everything is POST and you can do a lot of funky stuff however in REST world there is a standard on what method used for what purpose ideally.
I'm currently developing a web application with a senior developer. We've agreed to use REST API for client-server communication and he sent me the parameters and the expected responses.
But the design does not seem to be RESTful. Rather it looks like JSON-RPC over http utilizing only the POST method.
For example, to register a user you send a POST request to the server the following parameters.
{
id: 1,
method: "RegisterUser",
params: {
firstName: "John",
lastName: 'Smith',
country: 'USA',
phone: "~",
email: "~",
password: "~"
}
}
And the expected response is
{
id: 1
result: "jwt-token",
error : null
}
Multiple requests are sent to the same URL and the server sends back the response based on the 'method' in the parameters. For example, to get a user info, you send a { method: "GetUserInfo", params: { id: ~ }} to the same URL. All responses have the status code 200, and the errors are handled by the error in the response body. So even if the status code is 200, if error is not null it means something is wrong.
The way I'm used to doing is sending a POST request to 'users/' with a request body when registering a new user, sending a GET request to 'users/1' to retrieve a user information, etc.
When I asked why he'd decided to do it this way, he said in his previous job, trying to add more and more APIs was a pain when following RESTful API design. Also, he said he didn't understand why RESTful API uses different HTTP verbs when all of them could be done with POST.
I tried to come up with the pros of REST API over JSON-RPC over http with POST.
GET requests are cached by the browser, but some browsers may not support POST request caching.
If we are going to open the API to outside developers, this might cause discomfort for them since this is not a typical REST API.
In what circumstance would the JSON-RPC over http style be better the REST RESTful APIs? Or does it just not matter and just a matter of preferance?
it looks like JSON-RPC over http utilizing only the POST method.
Yes, it does.
The way I'm used to doing is sending a POST request to 'users/' with a request body when registering a new user, sending a GET request to 'users/1' to retrieve a user information, etc.
That's not quite it either.
Riddle. How did you submit this question to stack overflow? Well, you probably followed a book mark you had saved, or followed a link from google. Maybe you submitted a search or two, eventually you clicked the "Ask Question", which took you to a form. After filling in the details of the form, you hit the submit button. That took you to a view of your question, that include (among other things) a link to edit the question. You weren't interested in that, so you were done -- except for refreshing the page from time to time hoping for an answer.
That's a REST api. You, the agent, follow links from one state to another, negotiating stack overflows "submit a question" protocol.
Among other things to notice: the browser didn't need to know in advance what URLs to send things to, or which http method to use, because the HTML had encoded those instructions into it. The browser just need to understand the HTML standard, so that it could understand how to find the links/forms within the representation.
Now, REST is just a set of architectural constraints, that boil down to "do it the way a web server does". You don't need to use HTML as your media type; you don't need to design for web browsers as your clients. But, to do REST, you do need hypermedia; and clients that understand that hypermedia type -- so it is going to be a lot easier for you to choose one of the standardized media types.
Are there more reasons why I should prefer RESTful API over JSON-RPC over http with POST? Or does it just not matter?
Roy Fielding, in 2008, offered this simple and correct observation
REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them.
For instance, the folks working on GraphQL decided that the properties that the REST constraints induce weren't valuable for their use case; not nearly as valuable as being able to delivery to the client a representation tuned to a clients specific needs.
Horses for courses.
Use RESTful APIs when you are performing standard create, read, update and delete actions on resources. The CRUD actions should behave the same way for each resource, unless you have some before and after hooks. Any new developer coming to the project will easily understand your API if it follows the standards.
Use JSON-RPC when you are performing actions that don't necessarily map cleanly to any CRUD. For instance, maybe you want to retrieve counts or summary data of a specific resource collection. You could do this with REST, but it might require you to think of it as some sort of "summary" resource that you read from. It's easier to do with JSON-RPC, since you can just implement a procedure that runs the appropriate query in your database and returns an appropriate result object.
Or what if you want to make an API call that lets a user delete or update all of instances of a resource(s) that meet some condition, without knowing ahead of time what those instances are?
You can also use JSON-RPC in cases where you need to have a lot of side effects for standard CRUD actions and it's inconvenient to make hooks that run before or after each action.
You don't have to go all in with one of the other, you can use both. Have standard RESTful endpoints where appropriate and another RPC endpoint for handling JSON-RPC calls.
Use REST when you write public web services. REST is standardized and predictable, it will help consumers to write client apps. Also, GET HTTP method is widely used to retrieve resources from public web services.
Use JSON RPC when you write back-end for an application (i.e. not public web services). JSON RPC style is more flexible and more suitable for register, login, and getProductsByFilters methods. There is no reason to use GET with JSON RPC, only POST should be used.
Lets say im using an mvc application and either a create or getDetails function is called in AJAX, to help with page load times.
Someone could easily look through the DOM there and get the URL of where you do your JSON request.
that person could then easily write a little javascript snippet that calls that request 500 times per second and DDoS your site.
Seen as you cannot hide your AJAX / JSON requests from the DOM, is there any way to avoid this?
Using AJAX is not any more or less dangerous than not using it. That person could easily write little javascript snippet that sends 500 requests per second to a usual web page. That would make the same DDOS effect. You need a different approach to protect your website against DDOS attacks. IP base rate limiting is a fine method of doing that.
Do I need to use a form (formbuilder) to submit POST Data to symfony? For example login by xml or something like that?
I'm confused as there are people telling me I have to, and on the other hand there an some who tell me that I don't need to because I use it as a REST api???
It would be great if we can go through the possibilities I have with REST and CRUD.
I'm a bit confused because in case of a login, I don't want to nind a request to a form or an entity or is this the only way handling eg. login data?
Thanks in advance for your help.
Actually I think it's your own choice. There is no requirements to do things in single way. Do you think you need form - use form, no - no.
I think if action from your REST API doesn't relate to any entity it's absolutely not necessary to use forms. But if the action is aimed to handle CRUD request (POST or PUT) it's more convenient way to use forms. But anyway it's only your choice.
In some cases (in standard and pretty simple cases) it's much easier to use form and I think it's the best and fastest way to make something work. But if you need to customize form it might be too difficult and might take some time to solve all of the issues.
One approach to "login" is to think in terms of access tokens.
POST /tokens with a payload (xml or perhaps json) of user name and password. The server authenticates the user, then generates and returns an unique token linked to the user.
On subsequent REST requests, include the token in the header of the request. From the token, the server can determine the user and access protected resources accordingly.
http://symfony.com/doc/current/cookbook/security/api_key_authentication.html
This of course is only one approach that has worked for me.
===========================
By the way, #Alex of course answered your actual question on forms.
Ok before you jump to some conclusion like I'm looking for a free lunch or something of the sort, read the description entirely.
I have experience only in making small simple apps in PHP, Java and ASP.NET. I had no idea what GET, SET etc exactly are and what REST services are. To try to use the Twitter API, I did some reading and got to know (I might be wrong here, because this is what I THINK that I know..) that you can make a GET request like this one:
http://api.twitter.com/1/statuses/user_timeline.json
Using, say, cURL (I haven't tried it yet), and you get a JSON object returned which contains the statuses on your timeline in a certain format. And I verified this from here
But I don't understand how does Twitter know that it is ME and return only MY data? Where am I sending my account details?
What I want is for the use to come to my website, click a button to give my application the permission to access his/her Tweets and I do some processing in PHP and display the output. But I don't know where do I start from?
I am not asking you to give me bread, I'm asking you to tell me what should I do to learn to fish?
All tutorial I have been following till now have been sort of spoon fed where they say things like 'Download this php file from our site, include it in your source file, use this method to do this and that method to do that.'
This one is a change for me, so does anyone have any pointers? Is there any reading that I should do or approach that I must follow to learn that I'm doing wrong?
EDIT : I know there are 3rd party libraries out there and it might be easier to learn to use those, but I want to have an idea of how the people who made those did it.
To use Twitter (at least its REST API), you had better to read tutorials about the following things :
REST architecture because it is how Twitter communicates with your application.
HTTP requests. Useful for Authentication of requests (HTTP headers), kinds of HTTP requests (GET and POST for the Twitter API) and return codes of requests.
OAuth which is the protocol used by Twitter for authenticating requests.
Format of datas returned by Twitter after the requests. Most of the time it is JSON but it can also be like in a URL query string (for OAuth authentications). You are lucky because before there were XML and Atom (for RSS feeds) too.
And of course the Twitter Documentation to know how they use all that stuff, how they know that is YOU with THIS application (request authentications) and to know the objects manipulated by the API (mainly tweets, users and timelines).
Good luck for it !