Sono nuovo di REST e sto lottando per capire come si possa progettare correttamente un sistema REST sia per consentire un accoppiamento lento, ma allo stesso tempo consentire a un consumatore di un'API REST di comprendere l'API.
Se, nel mio codice cliente, emetto una richiesta GET per una risorsa e recupero XML, come faccio a sapere cosa fare con quel xml? per esempio. se contiene <fname>John</fname><lname>Smith</lname> come faccio a sapere che questi si riferiscono al concetto di "nome", "cognome"? Spetta alla persona che scrive l'API REST di definire nella documentazione in qualche posto cosa significano tutti i campi XML? Cosa succede se il produttore dell'API desidera modificare l'implementazione in <firstname> anziché <fname> ? Come fanno questo e notificano ai loro consumatori che questo cambiamento è avvenuto? Oppure i consumatori incontrano semplicemente l'errore e poi guardano il carico utile e capiscono da soli che è cambiato?
Ho letto in REST in Practice che usare uno strumento WADL per creare un'implementazione client basata sul WADL (e nascondere il fatto che si sta facendo una chiamata distribuita) è un "anti-pattern". Ma stavo progettando di farlo - almeno allora avrei una chiamata API tipicamente statica che, se fosse cambiata, saprei in fase di compilazione e non in fase di esecuzione. Perché è una cosa brutta generare un codice client basato su un WADL?
E come faccio a sapere cosa fare con i collegamenti restituiti nella risposta di un POST a un'API REST? Cosa definisce questo contratto e dà un vero significato a ciò che ogni link farà?
Per favore aiuto! Non capisco come passare da staticamente-digitato o anche da SOAP / RPC a REST!