Re: [Regops] draft-wullink-restful-epp-00.txt
"Gould, James" <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <CBBC12B2.1C97E%[email protected]> |
Our EPP HTTP transport included the following: 1. Client sends an HTTP GET 2. Server returns the EPP Greeting with session cookie in the header (JSESSIONID) 3. Client sends command with HTTP POST and the session cookie as an HTTP header 4. Server returns EPP Response This is done in a 2-way SSL connection similar to the EPP TCP transport and HTTP keep-alive was used to maintain the stateful connection. We stopped supporting the EPP HTTP transport. -- JG James Gould Principal Software Engineer [email protected] 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 4/24/12 4:31 AM, "Klaus Malorny" <[email protected]> wrote: >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