Visualizzazione dei risultati da 1 a 9 su 9
  1. #1

    Cosa comunicare al client Web Service

    Ragazzi ho scritto un servizio in php per delle applicazioni che lo richiameranno, di queste applicazioni due sono mie, altre non saranno scritte in PHP, cosa debbo comunicare al client per far si che possa richiedere il servizio.

    il web service è con architettura REST.

    Io avrei pensato
    - l'endpoint(URL) dove è fruibile il servizio,
    - il tipo di metodo(GET, POST, DELETE, PUT),
    - l'URI Template
    - i parametri di accesi al metodo
    - il tipo di formato(XML, JSON).

    Servono altre informazioni al client?

  2. #2

    Re: Cosa comunicare al client Web Service

    Originariamente inviato da supersonic84
    Ragazzi ho scritto un servizio in php per delle applicazioni che lo richiameranno, di queste applicazioni due sono mie, altre non saranno scritte in PHP, cosa debbo comunicare al client per far si che possa richiedere il servizio.

    il web service è con architettura REST.

    Io avrei pensato
    - l'endpoint(URL) dove è fruibile il servizio,
    - il tipo di metodo(GET, POST, DELETE, PUT),
    - l'URI Template
    - i parametri di accesi al metodo
    - il tipo di formato(XML, JSON).

    Servono altre informazioni al client?
    Ciao,
    direi la struttura dei dati in ingresso e in uscita (sempre che tu con URI template non intenda questo). Inoltre eviterei una doppia presentazione XML/JSON ma la gestirei via parametri, cioè è il cliente che chiede i dati o in XML o in JSON tramite un parametro nella richiesta.

    Prevedi anche una chiave di accesso, tipo un md5 univoco per cliente.


  3. #3

    Re: Re: Cosa comunicare al client Web Service

    Originariamente inviato da Dascos
    Ciao,
    direi la struttura dei dati in ingresso e in uscita (sempre che tu con URI template non intenda questo). Inoltre eviterei una doppia presentazione XML/JSON ma la gestirei via parametri, cioè è il cliente che chiede i dati o in XML o in JSON tramite un parametro nella richiesta.

    Prevedi anche una chiave di accesso, tipo un md5 univoco per cliente.

    Ciao Dascos, per URI Template intendo questo myservice/?user{username, id}, va bene come struttura dati o sono fuori strada?
    Per il formato ho gestito come hai detto tu proprio.

    Per la chiave di accesso cosa intendi?

  4. #4
    Ciao,
    ok ho capito.
    Direi che la URI non vada costruita in quel modo. I dati di accesso (la chiave univoca) la passeri dentro il payload, nella sezione header. Sempre nell'header metterei il metodo (get, put eccetera).
    Nel body invece metterei i dati di ingresso e/o quelli di uscita.

    Per chiave univoca intendo un codice, magari un md5 tipo md5("mariorossi" + "alfaBetaCharly") dove "mariorossi" è variabile in base all'utente ma "alfaBetaCharly" è fisso, che sostituisca lo userid o lo username, in modo da rendere più complicato lo spoofing. Ovviamente dovrai trovare il modo di comunicare questo md5 a ogni utente che voglia utilizzare il tuo sistema.

    In sostanza utilizzerei un wsdl: http://www.w3schools.com/wsdl/wsdl_intro.asp


  5. #5
    Originariamente inviato da Dascos
    Ciao,
    ok ho capito.
    Direi che la URI non vada costruita in quel modo. I dati di accesso (la chiave univoca) la passeri dentro il payload, nella sezione header. Sempre nell'header metterei il metodo (get, put eccetera).
    Nel body invece metterei i dati di ingresso e/o quelli di uscita.

    Per chiave univoca intendo un codice, magari un md5 tipo md5("mariorossi" + "alfaBetaCharly") dove "mariorossi" è variabile in base all'utente ma "alfaBetaCharly" è fisso, che sostituisca lo userid o lo username, in modo da rendere più complicato lo spoofing. Ovviamente dovrai trovare il modo di comunicare questo md5 a ogni utente che voglia utilizzare il tuo sistema.

    In sostanza utilizzerei un wsdl: http://www.w3schools.com/wsdl/wsdl_intro.asp

    Grazie per la dritta sulla chiave, per quanto riguarda i concetti di paylod, mi sono sconosciuti, non ho capito come definirli per chi deve sviluppare il client

  6. #6
    Originariamente inviato da supersonic84
    Grazie per la dritta sulla chiave, per quanto riguarda i concetti di paylod, mi sono sconosciuti, non ho capito come definirli per chi deve sviluppare il client
    Dovresti definire un wsdl (vedi link che ti ho messo prima) oppure fare come fa Google con per esempio l'interazione GMail, cioè pubblicare le strutture dei vari elementi: https://developers.google.com/google..._with_contacts

    Secondo me meglio usare un wsdl, ma qui sei tu che devi decidere in base a come hai effettivamente sviluppato il Web Service. Cosa utilizzi, lato server? SOAP?


  7. #7
    Originariamente inviato da Dascos
    Dovresti definire un wsdl (vedi link che ti ho messo prima) oppure fare come fa Google con per esempio l'interazione GMail, cioè pubblicare le strutture dei vari elementi: https://developers.google.com/google..._with_contacts

    Secondo me meglio usare un wsdl, ma qui sei tu che devi decidere in base a come hai effettivamente sviluppato il Web Service. Cosa utilizzi, lato server? SOAP?

    utilizzo rest, come ti avevo scritto, e leggendo sul web avevo notato che per rest non usavano un wsdl come si faceva per soap.

  8. #8
    Originariamente inviato da supersonic84
    utilizzo rest, come ti avevo scritto, e leggendo sul web avevo notato che per rest non usavano un wsdl come si faceva per soap.
    No, non è del tutto corretto.
    Anche in REST puoi usare WSDL ma in questo caso il WSDL lo usi solo per descrivere il formato dei dati e non per ricevere le informazioni...

    http://www.xfront.com/REST-Web-Services.html

    7. Specify the format of response data using a schema (DTD, W3C Schema, RelaxNG, or Schematron). For those services that require a POST or PUT to it, also provide a schema to specify the format of the response.

    8. Describe how your services are to be invoked using either a WSDL document, or simply an HTML document.

  9. #9
    Originariamente inviato da Dascos
    Ciao,
    ok ho capito.
    Direi che la URI non vada costruita in quel modo. I dati di accesso (la chiave univoca) la passeri dentro il payload, nella sezione header. Sempre nell'header metterei il metodo (get, put eccetera).
    Nel body invece metterei i dati di ingresso e/o quelli di uscita.

    In sostanza utilizzerei un wsdl: http://www.w3schools.com/wsdl/wsdl_intro.asp

    Dacos, quindi in base al fatto che utilizzo rest, e in base alla definizione qui sopra su come organizzare la cosa, cosa dovrei definire nel wsdl?

    Scusami le domande ma sono da pochi giorni sull'argomento.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.