我的API是RESTful API吗？

Question

I have been using Phalcon to develop my web system, and have added to it an API where orders can be sent through and stock numbers can be requested.

I am new to web services, so just wandering, is my API a RESTful API?

• All requests go through http://myurl.com/api .
• All requests have to put an "API-Key" in the header of the request which is used to authenticate.
• If they want to download the stock numbers, they send a "GET" to http://myurl.com/api/stock
• If they want to send an order through, then send a "POST" to http://myurl.com/api/order with a "data" parameter which contains a json_encoded array of the order details.

Returned data is usually a 200 status code with either success or fail (except invalid API keys which return a 401).

Answer 1

Does your service meet with the HTTP and URI standards? Does it serve a standard hypermedia format? Do your clients follow the hyperlinks given by the service, instead of building the followed URIs and methods on their own? Are the hyperlinks and the response data annotated with metadata, which can be used by the clients to understand what the response mean and how to process it? Do your client send the information necessary to identify the client with every request? Would these requests work after a complete server restart?

Answer 2

You can answer this question yourself. Maybe your API is a RESTful API.
But before that you need to know somethings...

1. What is RESTful Services/Programming..?
   I've got a nice and to-the-point for the same
   
   Some points summarized here...
   • URIs are the ubiquitous choice of identifier these days. Let URI be identifying every resource and services you wanna expose.
   • HTTP methods are used. Create , Retrieve , Update & Delete are handled by HTTP POST , GET , PUT & DELETE methods respectively.
   • Return the result with following appropriate HTTP Response Codes
     

2. Does your API
   
   Favor JSON support unless you're in a highly-standardized and regulated industry that requires XML, Schema validation and namespaces. And offer both JSON and XML unless the costs are staggering. Ideally, let consumers switch between using the HTTP Accept header, or by just changing an extension from .xml to .json on the URL.
   

   Be warned though, as soon as we start talking about XML support, we start talking about schemas for validation, namespaces, etc. Unless required by your industry, avoid supporting all that complexity initially, if ever. JSON is designed to be simple, terse and functional. Create your XML to look like that if you can.
   

   In other words, make the XML that is returned more JSON-like: simple and easy to read, without the schema and namespace details present—just data and links. If it ends up being more complex than this, the cost of XML will be staggering. In my experience nobody uses the XML responses anyway over the last several years. It's just too expensive to consume.
   

   To read more on How a RESTful API should be

3. Please read the valuable comments of this answer as well. It'll really help. (Also you can read the answer for if you want some more details)

Now, I think you can decide for yourself whether your API is a RESTful API