Difference between revisions of "SOAP"
Wiki-JoWalsh (talk | contribs) m |
Wiki-JoWalsh (talk | contribs) m |
||
| Line 1: | Line 1: | ||
| − | People say "SOAP vs [[REST]] so there is a [[REST]] page. | + | People say "SOAP vs [[REST]]" so there is a [[REST]] page. |
---- | ---- | ||
| − | + | == OGC == | |
| − | + | The OGC has been revising many of its W*S specifications to supply SOAP bindings. | |
| − | + | == INSPIRE == | |
| − | + | The Draft [[Network Services Architecture]] for the INSPIRE European SDI suggests that INSPIRE may require a SOAP binding for access to all network data services. This means WMS, WFS, WCS, CSW et al. If the behaviours of a SOAP interface are not fully-described in the OGC specifications, the OGC specifications will be revised. | |
| − | * http://www.somebits.com/weblog/tech/bad/whySoapSucks.html From Nelson Minar, who | + | The Network Services document offers 4 "arguments in favour" of SOAP bindings. |
| + | |||
| + | * SOAP web services are becoming the standard information technology and thus support more sustainable implementing rules | ||
| + | * SOAP web service ensure smooth and complete integration in development environments | ||
| + | * SOAP web services yield a direct and full integration with other web service environments | ||
| + | * SOAP web services have the possibility to support geo rights management services by using SOAP envelope data | ||
| + | * http://www.eu-orchestra.org/publications.html | ||
| + | |||
| + | ''The European Commission will launch a project to study in detail whether a SOAP/WSDL based approach is feasible for the INSPIRE network services.'' | ||
| + | '''Moreover all involved [[FOSS SDIC|SDIC]]s/LMOs are hereby requested to provide comments and reports on the usage of SOAP/WSDL in the frame of setting up an SDI.''' | ||
| + | |||
| + | == Reports from the wild == | ||
| + | |||
| + | It is necessary to put together a set of clear basic use cases and do as much benchmarking and testing as possible. If people are offering and documenting both SOAP and the common REST style interfaces to their repositories, what do the access statistics look like? | ||
| + | |||
| + | Are there user community experiences, documentable, on how widely SOAP/WSDL for geodata services are implemented in the wild? | ||
| + | |||
| + | == References == | ||
| + | |||
| + | * http://www.somebits.com/weblog/tech/bad/whySoapSucks.html From Nelson Minar, who architected several SOAP services for Google, on why Google moved to a REST approach. | ||
| + | |||
| + | [[Category:Standards]] | ||
Revision as of 08:43, 20 December 2007
People say "SOAP vs REST" so there is a REST page.
OGC
The OGC has been revising many of its W*S specifications to supply SOAP bindings.
INSPIRE
The Draft Network Services Architecture for the INSPIRE European SDI suggests that INSPIRE may require a SOAP binding for access to all network data services. This means WMS, WFS, WCS, CSW et al. If the behaviours of a SOAP interface are not fully-described in the OGC specifications, the OGC specifications will be revised.
The Network Services document offers 4 "arguments in favour" of SOAP bindings.
- SOAP web services are becoming the standard information technology and thus support more sustainable implementing rules
- SOAP web service ensure smooth and complete integration in development environments
- SOAP web services yield a direct and full integration with other web service environments
- SOAP web services have the possibility to support geo rights management services by using SOAP envelope data
- http://www.eu-orchestra.org/publications.html
The European Commission will launch a project to study in detail whether a SOAP/WSDL based approach is feasible for the INSPIRE network services. Moreover all involved SDICs/LMOs are hereby requested to provide comments and reports on the usage of SOAP/WSDL in the frame of setting up an SDI.
Reports from the wild
It is necessary to put together a set of clear basic use cases and do as much benchmarking and testing as possible. If people are offering and documenting both SOAP and the common REST style interfaces to their repositories, what do the access statistics look like?
Are there user community experiences, documentable, on how widely SOAP/WSDL for geodata services are implemented in the wild?
References
- http://www.somebits.com/weblog/tech/bad/whySoapSucks.html From Nelson Minar, who architected several SOAP services for Google, on why Google moved to a REST approach.