REST runs on top of HTTP so you're most of the way there. What a REST API returns has nothing to do with REST and is more to do with the application's domain.
You're using json_encode
to return JSON, which is fine and is perfectly acceptable as a REST return type. Another REST API might return a compressed CSV if bandwidth is tight or the device calling the API is resource constrained. What it returns is of less importance than how it's called.
REST refers to representation. So the client wants a representation of a resource at the server. e.g. this:
/api/user/{name}
can return the representation of a user in JSON format using json_encode
. e.g.
/api/user/smith
returns:
{
"nane": "Mr. Smith",
"email: "smith@smith.com"
}
if you use the REST verbs to work with that state then you're using REST.
The other aspect of REST that causes lots of debate is what the URLs look like. The URLs should ideally identify a resource and the verbs say how that resource should be interacted with, e.g. GET
a user
, POST
a new user
, PUT
updates to the existing user
, DELETE
an existing user
.
The operations performed on the representation of the resource are specified by the HTTP methods.
To answer your question about "normal" APIs, there aren't any. There is no API standard, however REST provides those two markers, resources as URLs and operations on those resources as HTTP verbs. Other types of API are xml-rpc where some people use that type of URL, e.g. POST
ing data to:
/api/user/new
the above isn't a RESTful URL as it doesn't identify a resource. It identifes an operation (new user).
SOAP is another type of API that is far more complex than REST but it was designed to do things REST doesn't need to do, such as routing and service discovery.
So in summary, if you expose your resources as URLs and use HTTP verbs to interact with them, you're using REST. Looks like you're good to go.