What I understand as of now, is that REST API is something like a call I make to a website and give me the results in the json format, that's all.
Not quite. Firstly, there is no requirement for REST to use JSON although many instances do. Secondly, REST is more specific in that it stipulates the creation, deletion and modification of data items via a structured path. The HTTP methods are respected as are HTTP status codes - REST therefore necessarily builds on HTTP. There is plenty of detailed documentation on the web about what REST is and what it isn't (eg https://en.wikipedia.org/wiki/Representational_state_transfer#Architectural_constraints).
If you could direct me to a good tutorial that teaches REST API using Perl, I will be ever so thankful.
Do you want to build a client or a server?
| [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] |
REST::Client will get you started.
There are many more clients for specialized REST services - if you are using a well-known REST server, you will be better off using a pre-written specialized client.
Here is a brief Rest::Client tutorial.
"Imaginary friends are a sign of a mental disorder if they cause distress, including antisocial behavior. Religion frequently meets that description"
| [reply] [Watch: Dir/Any] |
Hi hippo,
I want to build a REST server using Perl. How can I do this? Please point some tutorial and CPAN APIs.
Thanks
| [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] |
A RESTful API is specific for HTTP* and utlizes the following characteristics of HTTP to provide implicit caller and handler semantics:
- HTTP methods (GET, POST, PUT, DELETE, etc) - look up "CRUD" wrt "REST"
- HTTP response codes
- URL paths as entities and verbs
- headers defining content type of request body and types of serialized output you will 'accept'
Among other things, the goal is to not have an explosion of endpoints and to specifically avoid explicit "remote" procedure calls via URL and query parameters.
I also recommend reading the Felding's thesis on REST or at least a break down of it.
In practical terms it boils down to using something as simple as HTTP::Tiny and paying very specific attention to the request method, endpoint URL, and payload (request body). You then take the response, it'll be taken as a combination of: HTTP Status (200, 404, etc), content type header, and request body (usually as serialized JSON or XML). The latter is what you're thinking might be JSON or XML, which you extract from the response object and then deserialize using something JSON::XS.
I can't stress enough the REST is specifically defined for HTTP. Its principles can be extended to other protocols, but it will not look the same (some have tried to apply REST to things like "web sockets", all have failed). | [reply] [Watch: Dir/Any] |