Re: [Regops] draft-wullink-restful-epp-00.txt

Using a static URL and the http POST method to submit EPP XML messages will work fine.
But I think using REST will help in creating an easier to use EPP API.

As mentioned before, when using REST the EPP request message is optional for
commands like check, delete and info. These will (in most cases) no longer require a request EPP message.
The URL and HTTP method provide all the required information to perform the request.
(the authentication info can be transmitted with Authorization: Basic header)

"multiple ccTLDs use proprietary implementations of EPP over HTTP(S)."
I am interested to know which ccTLDs have such a implementation and what their experiences are.


Example domain name info:

Rest style

GET /domains/example.com

VS plain http POST

POST /command [postdata = epp xml domain name info request]


Personally I like the REST style more, no need for XML request message and informational URL.


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Klaus Malorny
Sent: dinsdag 24 april 2012 10:31
To: [email protected]; [email protected]
Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt

On 23/04/12 19:05, Francisco Obispo wrote:
>
> You could initiate a session with a RESTful server, just like most websites
> work:
>
> - You will use a RESTful URL to create a session: /session/user_id [POST]
>
> - The server would return a cookie, which you will return with every RESTful
> request.
>
> - When you're done processing requests you can: /session/user_id [DELETE]
>
> The advantage of this model, is that you can use the existing knowledge on
> how to scale web-services and apply them to Registry-Registrar interactions.
>
> Francisco
>
>

Hi,

if you are using cookies, so why use REST at all? AFAIK, multiple ccTLDs use 
proprietary implementations of EPP over HTTP(S). These use more or less POST 
requests to a static URL, containing the command as the POST data and the 
response in the HTTP response body (hello/greeting, login and logout 
accordingly). Session state is maintained by cookies. It does not require any 
changes to the base protocols (RFCs 5730-5733) and also avoids my personal 
disfavoured REST concepts of giving up the self-containedness of the payload and 
using different payload formats for requests and responses (which occur to the 
lesser extent in the proposed standard). So IMHO it would be better to focus on 
the standardization of the existing flavours if there is a demand of an 
HTTP-based transport layer.

Klaus
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg