I just watched a video, that says it's a bad practice to create API like that
/applications/getUser
/applications/deleteUser
/applications/getUserAndWeather
and from what I understood, it's a good design to create something like User and initialize post, get, put, delete properly.
but what if in my android application there is a page that shows all users in addition to weather, should I combine those two independent resources into one single API called UsersAndWeathers(GET) or create one called getUsersAndWeather. or should I create two separate endpoints and let android application calls both of in parallel?
I know all solutions would finally work, but which is the best design?
It's good to make small single-purpose API endpoints, because not every client might need both at the same time, the results might appear at different speeds, and might have different rules around when you need to refresh them. Just generally you don't want to combine every API response in one giant one.
HTTP requests are not that expensive, so your default should be to make 2 endpoints like
/users
/weather
There are certain cases where combining responses is a good idea, but you should only consider making these combined endpoints if you have such a reason. Until then, do the simple thing.
If you do find that reducing requests is something you need to do later, I would recommend you look into standard JSON response formats like HAL and JSON:API as they all have built-in syntax to support this use-case.
I'm new to this game so I might be misunderstanding things. Actually, if someone tells me that I'm misunderstanding things, it will be a favor. Maybe this person will be considerate enough to show me the right path. But...
One of the "guidelines" or "best practices" of REST as it applies to Web Services (http://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_web_services) is that you should use the proper HTTP methods when making calls (did I misunderstand it?) to REST API's.
But looking at many API implementations on the web, what I see is that 100% of the calls made to them are actually GET calls that, depending on their URI, will be interpreted by the API as being of one of the HTTP verbs or methods.
So, for example, looking at the REST API documentation for Twitter (https://dev.twitter.com/rest/public) which, in principle, only defines two verbs/methods (GET and POST), actually have all calls sent as GET and, based on the URI in the GET call, are interpreted by the API and acted upon.
Example:
GET statuses/lookup: https://api.twitter.com/1.1/statuses/lookup.json
POST statuses/update (PUT?): https://api.twitter.com/1.1/statuses/update.json
In both cases, the call itself was made using GET and the last part of the URI defined it as a real GET or as a POST.
In summary, to be truly RESTful, shouldn't client side implementations of REST API's for web services use the proper HTTP verbs/methods?
What am I missing?
You're missing a lot, but don't worry about it, most people are.
The fact is that very few so-called REST APIs publicly available on the internet are really RESTful, mostly because they are not hypertext driven. REST became a buzzword to refer to any HTTP API that isn't SOAP, so don't expect for an API to really be RESTful just because it says it's a REST API. I recommend reading this answer.
From my experience, most API developers aren't aware what REST really is and believe any HTTP API that uses HTTP and avoids verbs in URIs is REST.
REST is defined by a set of constraints. Among them is the uniform interface, which in simple terms means that you should not change the expected behavior of the underlying protocol. REST isn't coupled to any particular protocol, but since it's common to be used with HTTP, they get convoluted sometimes.
HTTP has very well defined semantics for the GET, POST, PUT, DELETE, PATCH and HEAD methods, and the POST method has its semantics determined by the server. Ideally, a REST API should respond to the methods other than POST exactly as determined in the RFC 7231, but as you noticed, there are many APIs who call themselves REST but don't do that. This happens for many reasons. Sometimes there's a simple misunderstanding about the correct semantics, or it's done to keep consistency, or because of backwards compatibility with intermediaries that don't support all methods, and many other reasons.
So, there's a lot more that has to be done to be truly RESTful other than using the HTTP methods correctly. If an API doesn't get even that right, it needs to find another buzzword, because it's definitely not REST.
I can't exactly tell what your question is, but I believe there are some concepts that will help you. Allow me to elaborate...
You are correct that many APIs use a limited number of HTTP "verbs" in their API. GET/POST are the most common. PUT less so, and then all others (DELETE, HEAD, OPTIONS etc) are used with vanishing probabilities.
Dropbox Core API for file uploads allows optional PUT / POST and their stated reason is "For compatibility with browser environments, the POST HTTP method is also recognized."
Indeed the limitation is the browser. Popular web servers have no problem with all HTTP request methods and even made up ones. After all, the request method is just some string with regard to the web server.
HTML4 and HTML5 only allow GET and POST requests for form requests. If you want your API to be used through a browser at all - and hey why not, it sounds like a useful thing - then you're limited to GET/POST. For a useful discussion on this see: https://softwareengineering.stackexchange.com/questions/114156/why-are-there-are-no-put-and-delete-methods-on-html-forms
Further complicating things is the fact that REST is not an industry standard. There exists no RFC, ISO or other document detailing what a "compliant" implementation must and must not do. While many folks have been playing concepts related to REST for some time, the REST concept was "invented" in the PhD disseration of Roy Fielding. A fantastic read if you're interested in such things.
Yes, according to REST, APIs should be using the correct verbs. However, as long as the documentation is clear and all GET requests are idempotent, then life should continue smoothly.
(Source: I wrote PipeThru.com which integrates 40+ APIs, Dropbox and Twitter included)
I think that this link could give you some hints about the design of RESTful services / Web API: https://templth.wordpress.com/2014/12/15/designing-a-web-api/.
It's clear that not all Web services that claim to be RESTful are really RESTful ;-)
To be short, RESTful services should leverage HTTP methods for what they are designed for:
method GET: return the state of a resource
method POST: execute an action (creation of an element in a resource list, ...)
method PUT: update the complete state of a resource
method PATCH: update partially the state of a resource
method DELETE: delete a resource
You need to be also to be aware that they can apply at different levels, so methods won't do the same things:
a list resource (for example, path /elements)
an element resource (for example, path /elements/{elementid})
a field of an element resource (for example, path elements/{elementid}/fieldname). This is convenient to manage field values with multiple cardinality. You don't have to send the complete value of the fields (whole list) but add / remove elements from it.
Another important thing is to leverage HTTP headers. For example, the header Accept for content negotiation...
I find the Web API of Github well designed and its documentation is also great. You could browse it to make you an idea. See its documentation here: https://developer.github.com/v3/.
Hope it helps you,
Thierry
You are correct. If they want to be "RESTful", their API should respect the semantics of each HTTP method.
Roughly, REST is about method Information (what the server should do), scoping information (where the server should do it) and, I almost forgot to mention, hypermedia driven (make sure you check #PedroWerneck's great answer to this question as it talks about it a little more and referecences a blog post from Fielding on the matter).
What the API you mentioned does is have both method and scoping information in the URL. That would not fit the RESTful architecture very well, as it, in general terms, tells us to:
1) use the HTTP methods the proper way (respecting their properties, such as idempotency and others), and
2) use unique URIs to identify unique resources.
Point 1 says "use HTTP methods to convey method information" and point 2 says "use URIs to convey scoping information".
Again, if an API uses GET with a specific parameter in the URI to do something (and not get something), then it is using URI to convey method information.
Now, don't be alarmed. Most APIs out there are just RESTful-ish (like twitter's of flickr's), meaning they are an animal between REST and something else. That is not bad per se, it just means they will not fully benefit from what RESTful architectures (and HTTP) have to offer.
Remember that being RESTful isn't just a matter of fashion, it does have its benefits, such as statelesness, adressability, and so on. And those can only be fully achieved by using the HTTP verbs like they were supposed to be used.
About using POST instead of PUT, considering they have different properties (PUT is idempotent, POST is not), it is not bad to use POST, as long as it is uniformly designed, that is, a programmer should not wonder what POST will do for each and every URI in the API: they all should behave the same. (PUT does not suffer from that because it already is uniform.) I talked a little more about this - and quoted Roy Fielding's say on it - in another question (check out the "Wrapping Up" part).
Consider looking at REST Richardson Maturity Model topic.
This specification is about how much RESTful particular API is:
Level 0:
Simple GET and POST request to descriptive url
/getUserByName?name=Greg
Level 1:
Divide all content in resources and define actions in resource group
/user/getByName?name=Greg
Level 2:
Proper use of HTTP verbs.
GET /user/Greg
Level 3:
Use hypermedia controls
Different APIs in interent implement different maturity level of REST. That's why some APIs don't support all HTTP features.
I am trying to create a REST API for my web service.
I want to make the users of the API able to initiate a new request with my service. This involves uploading one or two zip files along with some other parameters.
How can I make this all combined into one request? Or is it better to do it multiple requests somehow?
I don't have a lot of familiarity with making REST APIs so I don't know how people usually do it.
I'm using PHP for my site if that matters.
To do this, you'd need your client to upload in mime/multipart format. I don't know PHP, but I'm sure there's a library out there that will support receiving/parsing the multipart messages you get.
As for whether it's a good idea .. If initiating the request is the creation of a single resource, it's not unreasonable to accept mime/multipart. If the parts being sent are themselves full-fledged resources, it would probably be better to make the client send them up separately, and reference them in the initiation request. Also note that mime/multipart is going to be a bit harder for your clients to deal with than simple requests.
This post seems to be related to what you're trying to accomplish.
Rest confuses me sometimes. I know that it involves creating an API layer over your data and then you make calls to that data through the API. The best way I think of Rest is that the actual Twitter website interfaces with the data-layer through API calls.
That made me wonder then: Is a backend-service like Parse also a Rest API to your data?
What might be the difference between Parse and say, building your own Rest API like this guy did: http://coenraets.org/blog/2012/10/nodecellar-sample-application-with-backbone-js-twitter-bootstrap-node-js-express-and-mongodb/ (he's getting some solid google rankings for his API tutorials).
A simple yes/no might answer the question, but providing details will really be appreciated.
I look forward to the answers.
Parse is built around a restful API just like most, if not all, other mBaaS out there.
A RESTful Api isn't just CRUD operations though nor is it the same thing as Parse. Parse is a company that provides a remote backend to developers using a RESTful api.
RESTful api !== BaaS
I have dealt with about 5 mBaaS and Parse isn't really one of them, but I've glanced at their API reference for JS and I think they use mongodb clusters. An mBaaS usually provides the developer the ability to have cloud storage, push notifications, server side code, easier social media integration, and mobile analytics. So it's not just any backend. Although there are some mBaaS, like Urban Airship, that only supply push notifications to developers.
A RESTful api at it's core usually has some key functions that are centered/wrapped around an httpRequest
They usually use "GET", "POST", "DELETE", and "PUT" to make all calls. Some allow the implementation of rpc for custom server logic. An mBaaS takes a lot of work to implement right and well. You can't build Parse in a Day. It takes a lot of planning and such. The differences between Parse and that guy in link are in the implementation, range of features, and purpose in general(the audience).
To better understand REST maybe look here you can also read the HTTP spec if you are feeling adventurous.
I have 2 different Rails application and I want these apps to send and receive information via an API. What is the correct way to do this?
I was trying to use this resource but I don't quite understand it: http://api.rubyonrails.org/
(I am not sure how to make the call for the different methods. Some methods show an URL which I guess I wouldn't have too much problem implementing, but what if the application is within the same server, what would be the correct way to call a corresponding API method.)
Is there a recommended beginners resource out there?
Thanks.
api.rubyonrails.org is Ruby on Rails documentation, so this is API of RoR. What you want is external HTTP, probably REST and probably JSON API.
There are many resources on building REST API's. In general you have to prepare some endpoints that application can send request to and handle responses.
Take a look i.e. on railscast about using active model serializers. This would be the part where you give other application endpoints to get or change data.
Normally you would stop here because in most cases you set API for other applications (like mobile or javascript applications). But in your case you will need something to send requests. There are many gems that allow that, but I find Faraday gem most useful.